Implementation: DESIGN (server) · Exposure: PUBLIC PREVIEW (contract). The Agency API is not live yet. This page describes the published v0.3 contract so you can review and build against it; details may change before alpha.
A receipt is append-only, content-addressed evidence of an effect, an input, a policy decision or a verification result. Receipts for a run form a hash chain and each one is signed. For the concepts see Receipts. Today the signed, hash-chained receipt chain runs inside the internal work runtime, covering effect receipts. The keys and chain-check routes are served only by that internal service; they are not exposed through https://api.allternit.com, and the Agency API endpoints on this page are not served yet. Receipt-backed completion is part of the alpha gate (restart, resume, verify, replay, receipt-backed completion).

Endpoints

The Receipt object

Receipt IDs start with rcpt_.
  • content_hash is SHA-256 over the canonical JSON (RFC 8785, JCS) of every field except content_hash and signature.
  • prev_hash is the previous receipt’s content_hash in the same run. It is null only at index 0.
  • A correction appends a new receipt with supersedes set. Receipts are never edited.
  • payload is an open object whose shape depends on type. Component identities appear in it only with view=debug.

Receipt types

ReceiptType

Signature

signature (ReceiptSignature): The signed material is the JCS-canonical form of {schema_id, schema_version, domain, content_hash}. Including the schema ID, schema version and the domain tag allternit.receipt.v1 means a signature cannot be reused for another schema, version or protocol.

Provenance

provenance items (Provenance):

List receipts

The append-only receipt chain for the run, in chain order.

Parameters

type takes a comma-separated list, for example ?type=verification,policy. A filtered list is not a complete chain; fetch without type to verify.

Responses

ReceiptPage:

Example

Hashes, signature values, key IDs and schema IDs in this example are illustrative, and the payload bodies are left empty.

Verify a receipt chain

A server-side check of the run’s receipt hash chain and signatures. This endpoint is a convenience, not the trust root. Clients can verify independently with content_hash, prev_hash, signature and the published keys.

Parameters

Responses

ReceiptChainVerification:

Example

signatures_valid is null if any receipt is unsigned. When a check fails, first_invalid_index is the index of the first receipt that does not verify.

Get a receipt

Parameters

Responses

Example

The response is one Receipt.

Get verification keys

Returns the JWKS document containing the Ed25519 public keys referenced by ReceiptSignature.key_id. This endpoint needs no authentication.

Responses

Jwks:

Example

Verify independently

The steps:
  1. Fetch every receipt for the run, unfiltered, in chain order.
  2. For each receipt, drop content_hash and signature, canonicalize the rest with RFC 8785, hash with SHA-256 and compare with content_hash.
  3. Check index is sequential and prev_hash equals the previous content_hash (null at index 0).
  4. For each signature, canonicalize {schema_id, schema_version, domain, content_hash} and verify the Ed25519 signature (value, base64url) with the JWKS key whose kid matches key_id. Check domain is allternit.receipt.v1.
The examples use third-party open-source libraries for RFC 8785 canonicalization and Ed25519: rfc8785 and cryptography in Python, and canonicalize plus the built-in node:crypto in Node.js. Fetch receipts with the default view, since the hash covers the receipt as served in that view.
This code follows the v0.3 contract text. The chain and signatures are implemented in the internal work runtime, but the Agency API endpoints and public keys route are not served yet, so this code has not been run against the public API. Expect details to be confirmed at alpha.
  • The receipt.appended event
  • Run.effect_receipt_ids and Run.output.run_receipt_id on the Run
  • Replays, which are built from receipts and recordings