An agent can buy an HTTP response in seconds. Months later, someone may ask why that purchase happened, which wallet paid, and what came back.

That someone could be a customer reviewing spend. It could be an auditor tracing automated decisions. Tomorrow’s regulator will ask the same questions with statutory deadlines attached.

So we’re shipping records now.

What a future examiner will ask

Expect direct questions:

  • Which agent run requested the call?
  • What endpoint and input were used?
  • Which Base mainnet transaction settled the charge?
  • Did a retry create another purchase?

A transaction hash answers one part. The API record supplies the endpoint version, input digest, HTTP status, and returned result.

Context matters at small prices too. Agentutility currently lists 799 endpoints across 17 clusters, with calls priced from $0.001 to $0.50. A broken retry loop can repeat a cheap call thousands of times before a human sees the bill.

The record has to survive longer than the process that made the request.

Idempotency keys belong on paid calls

An idempotency key identifies one intended purchase. The client creates it before sending the first request and keeps it unchanged across network retries.

For your own paid API, the request pattern can look like this: 

POST /<endpoint-slug> HTTP/1.1
Idempotency-Key: 01K3D7M8J2T4Q9V6P1X5C0R8AZ
Payment-Signature: <x402-payment-signature>
X-Client-Reference: planner-run-8841
Content-Type: application/json

Bind that key to the HTTP method, path, payer, and request digest. An exact retry should return the original result with the same receipt. Reusing the key with different input should return 409 Conflict.

How long should the key remain valid? At least as long as your client might retry. Publish the retention window so agent routers can choose their retry policy without guessing.

And keep the client reference. That value joins the onchain payment to the agent’s own decision trace.

The receipt travels with the result

Receipts work best inside the successful response. The caller can persist one object at the same moment it accepts the answer.

Here’s a useful response shape: 

{
  "result": {
    "status": "ok",
    "data": {}
  },
  "receipt": {
    "receipt_version": "1",
    "request_id": "req_01K3D7PG7YQ2M6W4",
    "idempotency_key": "01K3D7M8J2T4Q9V6P1X5C0R8AZ",
    "client_reference": "planner-run-8841",
    "endpoint": "<endpoint-slug>",
    "amount": "0.005000",
    "currency": "USDC",
    "network": "base-mainnet",
    "payer": "0x4b2f...91ac",
    "transaction_hash": "0x7f31...c21a",
    "settled_at": "2026-08-23T15:42:11Z",
    "request_sha256": "sha256:8e63...f219",
    "result_sha256": "sha256:66a1...307c"
  }
}

Use decimal strings for money. Floating-point amounts create avoidable disputes. Record the network explicitly because 0x transaction hashes look alike across EVM chains.

The request digest lets a reviewer compare retained input with the paid call. The result digest does the same for output stored elsewhere. Raw payloads can follow a separate retention policy, especially when agents send credentials or customer text.

What we keep

For each settled call, we keep identifiers that connect the request with its payment. That includes the request ID and idempotency key, plus the endpoint and input digest.

The payment side records the payer, USDC amount, Base mainnet transaction hash, and settlement time. Response status and result digest connect the receipt to what the caller received.

Receipts also help during ordinary support work. Give us a request ID or transaction hash and there’s a precise call to inspect. Routers can store the same receipt beside their decision trace as soon as the endpoint returns.