Hash it, sign it, store it where it cannot be edited.
Every Invoance product follows the same path. This page describes that path and what a verifier checks at the end of it. The product pages below cover what differs.
- event_id
- 7c1e4b52-9a0f-4d2e-b6f3-2f8a61c0d9e4
- event_type
- policy.approval
- ingested_at
- 2026-09-22T08:14:07.412Z
- payload_hash
- a3f2b1c9d4e8f70b6c5a1e92d8f4037bc61a9e5d2f7c8b04e3a6d19f5c2b7e80
- signature
- ed25519 · 9f1c…e27a (64 bytes)
- issuer
- acme.com · domain verified
- POST /v1/eventsAPI key + Idempotency-Key
- Canonical JSONKeys sorted, stable bytes
- SHA-256payload_hash, request_hash
- Ed25519Your organization's key
- Append-only ledgerRows cannot be deleted
You send a record
An authenticated POST from your backend, with an Idempotency-Key so retries are safe.
It is canonicalized and hashed
JSON is normalized so key order and whitespace cannot change the result, then hashed with SHA-256.
It is queued
The API accepts the record and hands it to a durable queue. Delivery is at-least-once and inserts are idempotent, so a redelivery never creates a second row.
It is signed
A worker signs the canonical bytes with the Ed25519 key that belongs to your organization.
It is appended
The row lands in a ledger table where DELETE and TRUNCATE raise an error at the database level.
Anyone can check a record
The verifier holds a payload or a file. They hash it and compare the result with the signed record. No account is needed, and the SDKs can check signatures with no network call at all.
- Opens the proof linkNo account, no dashboard access
- Recompute the hashSubmitted payload against anchored hash
- match_result: truePlus issuer domain and signing time
| Hash | SHA-256 |
|---|---|
| Signature | Ed25519, one key pair per organization |
| Key storage | Private keys are encrypted at rest |
| Canonical form | Sorted keys, stable byte output |
| Ledger | Append-only. Database triggers block delete and truncate |
| Retention | Expired rows are sealed from reads, still verifiable |
| Public keys | Published, so signatures can be checked offline |
- A specific record existed in a specific form.
- It was signed by a specific organization at a specific time.
- What you are looking at still matches what was signed.
- A sealed trace has had nothing added, removed or reordered.
- That the underlying statement is true.
- That a decision was fair, legal or correct.
- That a document's contents are authentic.
- That you meet a legal or regulatory obligation.
Audit Logs
MechanismEvent Ledger
MechanismAI Attestation
MechanismDocument Anchoring
MechanismTraces
MechanismEvidence Rooms
MechanismRead the API, then send a record.
The quickstart takes one API key and one request.