How verification works
Every event anchored through Invoance produces a public, unauthenticated verification endpoint. Any third party, auditor, regulator, counterparty - can validate the integrity and origin of a record without contacting Invoance or accessing your systems.
Why public verification matters
Verification endpoints are publicly accessible. Recipients do not need an Invoance account, API key, or any relationship with your organization.
Verification can be performed offline using the public key, payload hash, and Ed25519 signature. You do not need to trust Invoance's response.
Every proof is signed with a key bound to your verified domain. Verification confirms both the record integrity and the issuing organization.
Proof data cannot be altered after anchoring. Verification URLs remain resolvable and consistent for the lifetime of your retention period.
Verification methods
Invoance supports three levels of verification, from lightweight hash comparison to full cryptographic signature validation. Choose the level appropriate for your use case.
Compare a SHA-256 hash against the anchored record. Available for events, documents, and AI attestations. The simplest form, confirms content hasn't changed.
POST /events/:event_id/verifyPOST /document/:event_id/verifyPOST /ai/attestations/:attestation_id/verifyclient.events.verify() / client.documents.verify() / client.attestations.verify()Pass the raw payload directly, the SDK hashes it client-side and verifies against the anchored hash. No need to pre-compute the hash yourself. For attestations, the SDK also supports verifying by raw canonical JSON string.
client.attestations.verify_payload() / client.events.verify(payload={...})The strongest form. Fetches the attestation, then verifies the Ed25519 signature entirely client-side using the public key. Proves no field has been tampered with, including the timestamp, hashes, and metadata. Zero trust in the server required.
client.attestations.verify_signature()Raw payload retrieval
For independent verification, you can retrieve the exact canonical JSON that was hashed and signed at ingestion time. This is the source of truth for recomputing hashes offline.
/v1/ai/attestations/:attestation_id/rawReturns the canonical JSON that was hashed and Ed25519-signed. Cached server-side for 5 minutes.
client.attestations.get_raw()/v1/document/:event_id/originalReturns the original document file uploaded during anchoring. Stream directly for large files, cached for small ones.
client.documents.get_original()Public verification endpoints
These endpoints require no API key and are safe to share externally. They are the canonical reference for any third-party verification of an anchored record.
https://invoance.com/proof/event/{event_id}Verifies any anchored business event. Returns hash, signature, timestamp, tenant domain, and verification status.
https://invoance.com/proof/document/{event_id}Verifies an anchored document's integrity. Upload the original file to confirm it matches the cryptographic fingerprint taken at submission time.
https://invoance.com/proof/ai/{attestation_id}Verifies an anchored AI output or decision. Includes model metadata, decision context, and cryptographic proof of the output at generation time.
Verification response
The proof endpoint returns everything needed to independently validate a record. No additional calls or trusted data sources are required.
https://invoance.com/proof/event/evt_4c8d2f{
"event_id": "evt_4c8d2f",
"status": "verified",
"payload_hash": "9f3a...c21e",
"signature": "ed25519:7b1c...a4f9",
"public_key": "invoance:pk_tenant_7b1c",
"tenant_domain": "acme.com",
"anchored_at": "2026-02-25T14:22:01Z",
"event_type": "invoice.approved",
"verify_url": "https://invoance.com/proof/event/evt_4c8d2f"
}Manual offline verification
Verification can be performed entirely offline using standard cryptographic tools. This is the strongest form of verification - it does not require contacting Invoance at all.
echo -n '{"type":"invoice.approved","data":{...}}' | sha256sum
# → 9f3a...c21e ✓ matches payload_hash# Using the SDK (recommended)
result = await client.attestations.verify_signature("att_id")
print(result.valid) # True
print(result.signed_data) # Full JSON that was signed
# Or using openssl manually:
openssl pkeyutl -verify -pubin -inkey pub.der \
-keyform DER -in payload.bin -sigfile sig.binGET https://api.invoance.com/keys/acme.com
# → {
# "domain": "acme.com",
# "public_key": "t3kLmNpQr7wYzA...",
# "algorithm": "ed25519",
# "key_id": "invoance:pk_a4e2f819"
# }
# → matches ✓Verification guarantees
The SHA-256 hash binds the proof to the exact content submitted. Any alteration to the payload produces a different hash and invalidates the proof.
The Ed25519 signature proves the proof was issued by the stated tenant's key. It cannot be forged without access to the private signing key.
The anchored_at timestamp is recorded at ingestion and is part of the signed payload. It cannot be backdated or altered.
Proof records are append-only. Once created, the data returned by the verification endpoint cannot change.
Verification can be performed offline. The cryptographic proof does not depend on Invoance remaining online or trusted.
Verification URLs remain resolvable for the duration of your retention period, even if your subscription changes.
What verification cannot prove
Verification is a technical guarantee, not a legal or factual one. Understanding its limits is as important as understanding its guarantees.
Invoance verifies that a payload was submitted and has not changed. It does not verify that the contents of the payload are accurate, legal, or genuine.
Invoance records that an event occurred and was signed by a tenant key. It does not verify that a specific human authorized or intended the action.
If the original payload was not retained, verification can confirm a hash but cannot reconstruct or display the original content.
Cryptographic proof is technical evidence. Whether it is admissible in a specific legal proceeding depends on jurisdiction and context. Consult qualified legal counsel.