How Audit Logs works.
Signed activity logs for each of your customers, with a viewer they can open themselves. This page covers the mechanism: what happens to a request, what is signed, and how someone outside your company checks it.
- Create an organizationOne audit organization per customer
- Send eventsCall the API from the code path where the action happens
- Invoance numbers and signsThe writer assigns the next seq inside a transaction, then signs the canonical bytes
- Your customer reads and verifiesThrough the portal, the embedded viewer, an export, or the offline verifier in the SDK
Create an organization
One audit organization per customer. Each has its own sequence and retention period.
Send events
Call the API from the code path where the action happens. An idempotency key makes retries safe.
Invoance numbers and signs
The writer assigns the next seq inside a transaction, then signs the canonical bytes.
Your customer reads and verifies
Through the portal, the embedded viewer, an export, or the offline verifier in the SDK.
| Ordering | Per-organization seq, assigned under a row lock. Gapless by contract. |
|---|---|
| Signature | Ed25519 over canonical event bytes, including seq |
| Redelivery | A redelivered message never burns a sequence number |
| Integrity check | GET /v1/audit/orgs/{id}/integrity |
| Offline verify | verifyAuditEvent(event) in every SDK, no network call |
| Retention | Set per organization, capped by your plan |
| API keys | Audit-scoped: audit:write to send, audit:read to query. Ledger keys are rejected |
How a third party verifies
Verification does not need an Invoance account or access to your systems. The verifier recomputes the hash from what they hold and compares it with the signed record.
- Opens the proof linkNo account, no dashboard access
- Recompute the hashSubmitted payload against anchored hash
- match_result: truePlus issuer domain and signing time
Try it against a real record.
Open the verifier, or create a record of your own on the free plan.