Skip to main content
Every successfully verified step writes an immutable, hash-chained audit record. Sandbox and production records are also publicly signed; when trusted timestamping is enabled, the RFC 3161 outcome is explicit. The record preserves the material needed to verify the wallet proof at the applicable disclosure tier. How it is built is covered in Verification & trust. This page is about getting at it: the id, who can see what, and the lawful path to the full record.

​
The audit id

Each record has a stable id of the form {session_id}_{stage} — e.g. sess_abc123_0 for the first step of sess_abc123. You receive it in two places: Persist the audit_id alongside your own case/order id in session metadata so you can pull the record back on demand.

​
Two tiers of disclosure

The same record is disclosed at two very different levels, by design.

Business — authorized

What the owning business can fetch with its API key: the proof, chain, timestamp status, Alentra signature, and encrypted blocks needed to reproduce the record hash. identify, light_sign, and sign also disclose their signer and any captured wallet evidence. age_verify remains redacted to its boolean and threshold.

Legal — full

The complete, decrypted record, including signer and wallet evidence for an age_verify step. It is reached only through Alentra’s internal, role-gated legal workflow after review — not with a customer API key.
This split is deliberate. A business can re-verify the wallet material for ordinary disclosures and signatures. An age check stays anonymous to that business because its DeviceResponse includes the identity used to compute the threshold. All sensitive blocks remain encrypted at rest.

​
Fetch the business record

Call GET /v1/audits/{id} with your API key. It is scoped to your active business. The response includes the canonical hash context, timestamp status/token, and sealed ciphertext; sandbox/production records also carry alentra_signature. For non-age primitives it includes decrypted signer and, for a wallet-backed completion, wallet_evidence.
proof.claims_digest commits an identify record to the requested claims. The returned signer lets you recompute that digest. For sign and light_sign, use wallet_evidence with the offline verifier to re-run the ISO mdoc proof instead of treating the compact proof.signature string as sufficient on its own.

​
Immutability and retention

Completed results are not customer-deletable. Neither account closure nor a self-service request can alter or remove a result, original completed-sign document, signature, audit row, encrypted evidence, or hash-chain link. Only artifacts explicitly classified as transient because no sign result completed may enter scheduled cleanup. The contractual evidence period and legal-hold process must be set in the signed customer schedule before production use; expiry of a minimum period is not an automatic deletion right. When a court order, subpoena, or other lawful proceeding requires the full, decrypted record — the attested identity behind a verification — that disclosure runs through a dedicated, human-reviewed channel, never a customer-facing API.
1

Submit a request

The requester files at alentra.app/legal with the audit id(s), the matter reference, and the legal basis for disclosure.
2

Review

Alentra’s authorized staff review the request against the proceeding. Submitting a request does not by itself compel disclosure.
3

Disclosure

Authorized staff fetch the decrypted record for review, compose the approved disclosure, and send the response by email. The decrypted record is not persisted in the admin console.
A legal request does not guarantee disclosure or any legal outcome. Alentra reviews the requester’s asserted identity, authority, and basis, then records the decision. Customers remain responsible for their own copies, notices, and legal obligations.