Quickstart

Get a receipt ID

Every receipt has a stable ID, surfaced in two places: as an APR ↗ chip on the artifact in its source app (Commander run, miniterms doc, Designer version, InvoiceUp follow-up), or by pasting any receipt ID into the lookup form on the verify.dekimu.com homepage.

Replace <id> in the commands below with a real receipt ID. Any string of [A-Za-z0-9_.:-] up to 128 characters is a valid ID shape.

1. Fetch the signed claim

The signed claim is the source of truth. Its body is what the issuer attested to; its signature commits the issuer's key to that body.

curl -s "https://verify.dekimu.com/api/v/<id>" | jq .

Returns a JSON object with id, kind, issuer, subject, iat (Unix seconds), kid (key ID), body, and sig (Ed25519 signature, base64url). CORS-enabled, cache-control: no-store.

2. Fetch the inclusion proof

The proof shows that the claim ID was committed to the signed daily Merkle root for its anchor date.

curl -s "https://verify.dekimu.com/api/proof/<id>" | jq .

Returns a JSON object with rootHash, date, rootKid, an inclusion Merkle path, and (when per-app sub-trees are active) an appProof nested object. The root is signed by Dekimu's audit-anchor key, published at /.well-known/dekimu-audit-root-keys.json.

3. Fetch the issuer's public keys

Use the kid from the claim to look up the public Ed25519 key the issuer signed with.

curl -s "https://verify.dekimu.com/.well-known/dekimu-claim-keys.json" | jq .

Returns a catalog of every active and rotated issuer key, keyed by kid. Each entry includes the issuer name, key algorithm (Ed25519), the public key in base64url, and rotation metadata (activeFrom / retiredAt). Long-cache (s-maxage=300); rotations are rare and announced.

Verify locally

With the claim, the proof, and the keys, you have everything you need to verify offline:

• Check the signature: re-serialize the claim's signed body and verify sig against the public key for kid.
• Check Merkle inclusion: walk the proof path; the resulting hash must equal rootHash.
• Check root signature: verify the root with the public key published at /.well-known/dekimu-audit-root-keys.json.

A worked example with openssl lives in the self-verify walkthrough.

When a claim doesn't verify

• Pending anchor. Daily roots seal at 00:05 UTC. A receipt minted today will return not_yet_built from /api/proof/<id> until tomorrow's root is built. The signed claim itself is already valid.
• Anchor cron behind. Check /api/anchor/health. A response with status: "stale" means the daily root is overdue — escalate, do not declare the receipt tampered.
• Signature failed. Either the claim was modified after signing (tampered) or the kid was rotated and you cached a stale key catalog. Re-fetch the keys, retry.