Prove
Every priced request is a receipt in your organization's hash chain under recovea-chain-v1. Export a period and re-derive every hash yourself.
On this page
Prove is the record you can check without trusting us. Every request the
gateway meters and prices is written as a receipt, and every receipt is chained
to the one before it by a published recipe, recovea-chain-v1. Export a period
and you can recompute every hash with nothing but SHA-256.
What the request carries
Nothing. The receipt is written from the metering of an ordinary request. The
response's x-recovea-request-id is the receipt's request_id, so a response
in your logs and its row in the ledger join on that one value.
What a receipt holds
Twelve fields, and no content:
| Field | What it is |
|---|---|
request_id |
the req_ id the response carried |
timestamp_ms |
the request's timestamp, Unix epoch milliseconds |
provider |
openai, anthropic, or openai_compatible for a declared upstream |
model |
the model that answered |
route |
the path, such as /v1/chat/completions |
tokens_in, tokens_out, tokens_cached |
the token counts your provider reported |
cost_micro_usd |
the cost in integer microdollars; 1000000 is one dollar |
price_list_version |
the reference price list that priced it |
basis |
measured or applied |
mandate_id |
a reserved field; an absent value is hashed as the empty string |
What the chain does
Receipts are chained per organization, in order. Each row's hash is the lowercase-hex SHA-256 of fourteen values joined by U+001F: the recipe id, the previous row's hash, and the twelve receipt fields in the order above. The first row's previous hash is sixty-four zeros. A row's own hash is never part of its input.
So each row's hash is an input to the next. A ledger row altered after the fact fails re-derivation at that row, and every hash after it fails too. The hash-chained ledger walks through re-deriving one receipt from the previous hash.
A request is chained once it is priced. A request that could not be priced is still on the platform's Requests page, with no cost, and it is not in the chain.
What comes back: the export
On the platform's Ledger page, choose a period and a format, JSONL, JSON or CSV, and export it. The page calls the same route your own session can:
GET /platform/v1/ledger/export?period=2026-09&format=jsonlThe file opens with a header: the recipe id, your organization, the period, the
genesis, the chain head (the hash of the last row at or before the end of the
period), the row count, the price-list versions the period used, and the line
the meter measures; the provider invoice is the bill. Then one row per
receipt, in chain order, each carrying the recipe id, previousHash, the twelve
receipt fields in camelCase, and its rowHash. The fields ts, cost and
lever follow as display companions; they are not hash inputs.
A period that starts partway through your chain starts from its first row's
stored previousHash, not from genesis, so any one month re-derives on its own.
The Ledger page re-derives the period's chain in your browser from the same
export and compares the result with the export's chain head.
Receipts and the export are on for every plan, Free included, with no flag and no tier gate.
What a receipt proves, and what it does not
- It proves the record has not been changed. A receipt is the provider's reported counts, priced at a named price-list version, in a sequence where any later edit breaks every hash after it.
- It does not prove the counts are true. The token counts are the ones your provider reported on its own response.
- It covers routed traffic only. A call that never reaches the gateway has no receipt.