Skip to main content
GET
Lists the calling agent’s receipts, paginated. Free; requires only X-Agent-ID.

​
Query Parameters

​
number
default:"all"
Last N days (1 to 365). Omit for all receipts.
​
string
One of data, verification, communication, commerce, infrastructure, agent_to_agent. The overview maps tools to categories.
​
number
default:"50"
Results per page. Maximum 100; larger values are clamped to 100.
​
number
default:"0"
Pagination offset
​
string
Inclusive lower bound on created_at (ISO 8601, e.g. 2026-05-01T00:00:00Z). With until, pages through a fixed window, which reaches receipts older than the 100-row cap when you tag value weeks later.
​
string
Inclusive upper bound on created_at (ISO 8601).

​
Signature

The signature covers memo and decisionContext along with amounts and statuses. The signed payload is the receipt’s public fields plus revision and a SHA-256 digest of metadata. The private provider cost is never signed. The signature and digest in the example are placeholders. revision starts at 1 and increments on every re-sign (status change, settlement, refund, reconciliation), so two signed copies of a receipt can be ordered from the signed bytes alone. The payload has no version field: the SDK’s canonicalizeReceipt defines the format, and verifyReceipt / oneshot-verify-receipt recompute it from exactly the fields this endpoint returns.

​
Audit fields

Each receipt carries the audit metadata the caller attached, plus the job_id that links it back to the call:
​
string | null
The job that produced this receipt. Equals the request_id returned by the originating tool call (result.request_id). job_id is not unique across receipts: one job can produce several (typically the email worker loop, which writes one receipt per message sent). The PATCH Tag Receipt Value request resolves a request_id or job_id to the most recently created receipt for that job. This GET endpoint only lists receipts and doesn’t accept those lookup parameters. To target a specific receipt, store its rcpt_… id. The caller’s memo / decisionContext are also copied into the receipt and can serve as match keys.job_id is a correlation handle, not an idempotency key, and does not deduplicate calls. Idempotency uses a separate client-supplied Idempotency-Key header. Where an endpoint applies it, the same key with a different body is rejected with 422. Replay and conflict checks don’t apply to access-token enrichment requests. Rules by endpoint:
  • email.send: optional. The response is cached in Redis for 24h; the same key and body replays the original 2xx.
  • enrichProfile / findEmail / verifyEmail: honored only when durable enrichment is enabled server-side and the caller is a wallet session, not an access_token session (see Remote MCP). On these three routes an access-token session skips the durable-replay check and always dispatches a fresh job, even with durable enrichment enabled. Wallet sessions get an auto-generated key when the caller doesn’t supply one. Replay is stored in a durable Postgres row, not a 24h cache, and does not expire.
  • POST /v1/tools/physical-mail/send: mandatory. Also stored in a durable Postgres row with no expiry; a same-key request with a different body is rejected, not replayed.
See the SDK’s idempotencyKey option.
​
string | null
Human-readable reason for the call, up to 1000 chars. Set with the SDK’s memo option or memo in the JSON body. See Audit Trail.
​
object | null
Machine-readable decision metadata for supervisor and auditor agents. Open schema; known fields include goal, goalId, alternatives, confidence (0-1).
A non-null value_tag counts toward RoCS only when its status is "confirmed". To tag, see Tag Receipt Value.