Skip to main content
Audact
See the offer

API · Evidence Vault

Receipts, retrievable and recomputable.

Public API host: In development

GET https://api.audact.ai/v1/receipts/{id}

The public API host. The code examples document the intended interface and the endpoints used within the current product.

No public API is served on this host yet, apart from the published Merkle roots at /v1/metachain. The endpoints used inside the product are not the same thing as a public API.

Why this status
Claim
In development · By application
Scope
The public API host. The code examples document the intended interface and the endpoints used within the current product.
Ground
No public API is served on this host yet, apart from the published Merkle roots at /v1/metachain. The endpoints used inside the product are not the same thing as a public API.
What it does not establish
That any individual endpoint works today. That is confirmed per endpoint, and the confirmation is open.
What you can get today
Production access sits inside an applicable paid agreement. Endpoints are not priced separately.
Last checked
5 October 2026
Where to check it
/apis

Production export: Working today · retested on 26 August 2026 after the deployPublic verifier: Not available yet

Everything the other five endpoints write lands here. Receipts are aggregated into a daily Merkle root and a single receipt is visible in the product. The production export of a set of receipts — JSON for a machine, PDF for a person — worked when it was retested on 26 August 2026 after the deploy — five calls, thirty validated turns, thirty receipts — measured on browser calls rather than over a telephone line. What the record itself gives you is unchanged: later alteration or reordering is detectable by recomputing against the stored commitment. That is the property, and it is a weaker and more honest claim than the word most vendors reach for.

GET /v1/receipts/{id}

{
  "receipt": {
    "receipt_format_version": "1.0.0",
    "call_id": "7f3c2a1e-0000-4000-8000-000000000000",
    "timestamp": "2026-08-15T10:14:23Z",
    "input_hash": "9b1d…e04a",
    "output_hash": "9b1d…e04a",
    "verdict": "ALLOW",
    "config_version": 12,
    "config_seal_hash": "4c2e…91d0",
    "policy_version": "DE_v1.1.0",
    "evidence_hash": "0b8e…7a13",
    "auth_mechanism": "hmac-sha256",
    "signature": "z3fx…c0de"
  }
}

The receipt as the engine issues it: JSON, canonicalised as described on /receipt-explorer, before the HMAC-SHA256 code is computed under a symmetric key held by Audact — not a public-key signature. `receipt_format_version` names the format, so an older receipt stays checkable when it changes.

GET /v1/receipts?from=…&to=…

curl -G https://api.audact.ai/v1/receipts \
  -H "Authorization: Bearer $AUDACT_API_KEY" \
  -d from=2026-08-01 \
  -d to=2026-08-31 \
  -d jurisdiction=DE \
  -d format=pdf \
  -d bundle=true

The call the production export will take, one per period per jurisdiction. The export itself worked when it was retested on 26 August 2026 after the deploy: five calls, thirty validated turns, thirty receipts, measured on browser calls rather than over a telephone line. The daily roots are designed to travel inside it, so a batch can be recomputed against them; those are the roots we supply, and the roots are published at api.audact.ai/v1/metachain. An export returns the receipts that match the period and jurisdiction you request. It does not establish that every call in that period produced a receipt.

What you get

Merkle aggregation: receipts are aggregated into Merkle roots per tenant; the roots are published at api.audact.ai/v1/metachain, and the batch export is designed to carry them.
Working today
Two export formats from one record: JSON for a machine, PDF for a person. Production export of a set of receipts. The export is sealed with an ECDSA signature; the receipts inside it carry their HMAC. The public key URL in the envelope does not resolve yet, so a party outside the platform cannot check the seal today.
Working today
The monthly evidence package is not in the offer.
Under validation
Per-jurisdiction retention windows; cryptographic erasure on the rest is coming soon.
In controlled testing
Sample artefacts to inspect before you write a line of code.
Working today
A public verifier, for a counterparty without an account.
Public verifier not available yet

What holds

Three fields anyone can recompute. No key, no account. A fourth, checked against the published root with the inclusion proof from the call's Article 50 report.

The hash of what went in, the hash of what came out and the link to the receipt before it are recomputable from the receipt itself: no key, no account. Recompute those three and any later change or reordering is detectable by recomputing against the stored commitment. The fourth, inclusion in the Merkle root, is checked against the published root with the inclusion proof from the call's Article 50 report; the report carries `event_inclusion_proof`, `cross_tenant_proof` and `merkle_root`, and `POST /v1/verify-inclusion` checks a branch proof without a key.

The authentication code is a different animal. It is HMAC-SHA256, computed with a symmetric key held by Audact. It is not a digital signature and there is no public verification key. Whoever can verify it can also produce it. It authenticates; it does not attribute.

Retention

Kept as long as the jurisdiction requires, and no longer.

Retention is set per jurisdiction, because the answer differs per jurisdiction. Where a record falls outside its window, the payload key will be destroyed and the chain entry will stay, so the sequence remains checkable while the content is gone; that erasure step is coming soon. That is what makes an erasure request under Art. 17 GDPR compatible with an evidence chain at all.

Questions

Can a regulator check a receipt without an Audact account?
The three recomputable fields, yes: with the file and a hash function. The fourth, Merkle inclusion, is checked against the published root with the inclusion proof from the call's Article 50 report. Public verifier not available yet: the roots are published at api.audact.ai/v1/metachain, but a service that performs the steps for you does not exist today, and no date is committed.
What does the PDF add over the JSON?
Readability, nothing more. It carries the same fields from the same record, laid out for someone who is not going to open a terminal.
What happens to the chain after an erasure request?
The entry stays and the content goes. The key that decrypts the payload will be destroyed, so the sequence and the hashes still line up while the personal data is unrecoverable. That erasure step is coming soon.

Look at the sample artefact first

A sample receipt in the production format: the fields the engine issues, with synthetic values. The input and output texts are included beside the receipt so the hashes can be recomputed; a production receipt carries only the hashes.

Recompute a chain yourself

The receipt explorer takes a sample chain and walks it: input hash, output hash, the link to the previous receipt, and the Merkle path. In your own browser, without an account.

Open the receipt explorer

Related