x402 for AI APIs: Follow the Second HTTP Request

AI x Crypto Systems disclosure: this article was prepared with AI assistance as an editorial helper. The ideas, facts, code, sources, and conclusions were reviewed by a human.

AI x Crypto Systems disclosure: this article is a technical explanation, not investment advice. AI x Crypto Systems does not recommend buying, selling, or holding any cryptoasset.

x402 for AI APIs

x402 for AI APIs is easiest to understand by following the second HTTP request. The first request asks for a paid resource. The server answers with 402 Payment Required. The second request carries the payment material and becomes the packet that deserves review. If an AI agent is allowed to sign that second request, the system needs more than a happy-path demo. x402 for AI APIs needs policy, replay handling, privacy review, and output validation around the payment.

GET /v1/report/42 HTTP/1.1
Host: paid-ai-api.example

HTTP/1.1 402 Payment Required
PAYMENT-REQUIRED: {"amount":"0.01","network":"base","resource":"/v1/report/42","expiresAt":"2026-05-25T09:31:00Z"}

GET /v1/report/42 HTTP/1.1
Host: paid-ai-api.example
PAYMENT-SIGNATURE: redacted-signed-payload

HTTP/1.1 200 OK
PAYMENT-RESPONSE: facilitator-result
Content-Type: application/json

Packet One

x402 for AI APIs begins with an ordinary request that cannot pay yet. Coinbase's x402 documentation describes the protocol as a way to enable programmatic payments over HTTP, using the long-unused 402 Payment Required status for paid resources. That framing is useful because it puts payment negotiation where API clients already operate. x402 for AI APIs turns a billing moment into a protocol moment.

Packet one should still be logged carefully. The path, method, host, resource category, and client identity can reveal what an agent is trying to buy. If the URL contains a document name, customer identifier, or prompt-like string, the payment trace can leak intent before any model output exists. x402 for AI APIs should make the first packet boring and redacted before a wallet ever signs the second packet.

Terms Packet

x402 for AI APIs becomes actionable when the server returns payment terms. Coinbase's "How x402 Works" page describes a server response with payment requirements in a PAYMENT-REQUIRED header, followed by a client retry that includes a PAYMENT-SIGNATURE header. Those fields are the protocol surface developers should inspect. x402 for AI APIs should not hide the terms inside an SDK abstraction when an agent is spending real money.

The terms packet should be treated as an offer with constraints. A useful trace stores amount, network, asset, resource, expiration, scheme, facilitator, and correlation ID. The trace should not store secrets or raw prompt content. x402 for AI APIs is attractive because it removes account friction, but the absence of an account does not remove the need for a policy decision.

Policy Pause

x402 for AI APIs needs a pause between the 402 response and the signed retry. That pause is where the agent runtime asks whether the spend is allowed. Base's AI agent payment guide shows an agent flow where a request receives payment requirements and then pays for the service. The missing production question is not "can the agent pay?" The missing production question is "why was this agent allowed to pay this endpoint now?"

The policy pause should be explicit:

Term	Policy question	Reject example
amount	Is this under task and daily budget?	10x expected price
network	Is this network allowed?	unsupported chain
resource	Is this endpoint allowlisted?	user-private export endpoint
expiry	Is the signature window short enough?	no expiration
reason	Is sensitive prompt text absent?	document title in URL

Signed Retry

x402 for AI APIs concentrates risk in the signed retry. The retry is not just another HTTP request; it carries a signed payment payload that can move value if the verifier accepts it. The retry should therefore bind the payment to the intended resource, amount, network, and time window. If the same signed material can be replayed against a different resource, the agent has delegated more authority than the task required.

The retry log can stay safe if it stores hashes instead of raw payment material:

{
  "request_id": "req_0902",
  "terms_hash": "sha256:4a91...",
  "resource": "/v1/report/42",
  "policy_decision": "allow: price below task budget",
  "wallet_role": "agent-limited-spend",
  "signature_stored": false
}

Facilitator Result

x402 for AI APIs can use a facilitator to verify and settle payment, but the facilitator is not a product-policy engine. Coinbase's x402 documentation describes facilitator involvement in verification and settlement. That helps sellers avoid running all payment infrastructure themselves. x402 for AI APIs still leaves resource authorization, abuse controls, refund rules, and service validation with the API owner.

This distinction blocks a subtle overclaim. A facilitator result can say the payment path worked. It cannot say the model response was fresh, true, complete, or allowed to be stored by the caller. x402 for AI APIs proves payment flow, not service quality. The paid response still needs version fields, source links, schema checks, and task-level validation.

Replay Lab

x402 for AI APIs should have a replay lab before a funded agent is allowed to use it. The lab does not need a large test suite at first; it needs negative cases that hurt in production. Expired terms should fail. Wrong resource should fail. Wrong amount should fail. Duplicate retry should be idempotent or rejected. Facilitator timeout should not trigger blind repeated spending.

The replay lab can be written as a small test table:

case expired_terms:
  send signed retry after expiresAt
  expect 402 or 409, no settlement

case wrong_resource:
  reuse payment for /v1/report/42 on /v1/report/99
  expect reject, no service body

case duplicate_retry:
  send same paid retry twice after timeout
  expect same response id or duplicate rejection

case facilitator_timeout:
  settlement state unknown
  expect stop automatic retry, require reconciliation

Metadata Leak

x402 for AI APIs can leak metadata even when the payment payload is valid. A paid endpoint can reveal which report, dataset, model, or customer workflow the agent is buying. Cloudflare's x402 policy discussion is relevant because it frames payments alongside policy, not merely settlement. x402 for AI APIs should treat resource descriptions, reason strings, URL paths, and facilitator-visible metadata as part of the privacy surface.

The safe trace stores categories where possible. Instead of logging GET /v1/legal-report/acme-merger-draft, the system can log resource_category=paid_report and a correlation ID. Instead of storing the full signed payload, the system can store a hash and settlement result. x402 for AI APIs should make a paid agent easier to audit without turning payment logs into a second prompt database.

Service Body

x402 for AI APIs returns a service body after payment, and that body deserves its own validation. A paid model endpoint may return stale data, a malformed JSON object, missing source links, or a response from the wrong model version. Payment success does not repair those failures. x402 for AI APIs needs output validators in the same runbook as payment validators.

The service body should carry model or data version, response timestamp, schema version, and validation status. If the endpoint sells research data, the response should link sources. If the endpoint sells model inference, the response should state model version and known limits. x402 for AI APIs lets the agent pay for the response; it does not certify the response.

Audit Event

x402 for AI APIs becomes reviewable when the final artifact is an audit event, not a receipt screenshot. The event should join the redacted first request, payment terms hash, policy decision, signed retry hash, facilitator result, service version, output validation, and retry decision. That object is the thing a team can inspect after unexpected spend.

{
  "request_id": "req_0902",
  "resource_category": "paid_report",
  "terms_hash": "sha256:4a91...",
  "policy_decision": "allow",
  "spend_limit": "task_budget_0.05_usdc",
  "facilitator_result": "settled",
  "service_version": "report-api-2026-05-25",
  "output_validation": "schema_pass source_links_pass freshness_fail",
  "retry_decision": "no_retry_without_human_review"
}

Idempotency Branch

x402 for AI APIs needs an idempotency branch because network errors happen in the worst possible place: after a signed payment is sent and before the client knows whether settlement completed. If the agent retries blindly, the agent can create duplicate payment attempts. If the agent never retries, the task may fail even though payment succeeded. The implementation needs a request ID that survives retry and a server behavior that returns the same result or a clean duplicate rejection.

The idempotency branch should be tested with a forced timeout. Send the signed retry, drop the client connection before the response body arrives, then repeat the paid retry with the same idempotency key. x402 for AI APIs passes this branch only if the server can reconcile the payment state without asking the agent to sign a fresh payment automatically. The branch proves duplicate handling, not service quality.

Budget Ledger

x402 for AI APIs also needs a budget ledger outside the payment protocol. The ledger should record task budget, amount quoted, amount settled, cumulative spend, and the policy that authorized the spend. Without that ledger, an agent can obey every payment rule and still drain a task budget through too many individually valid requests. The protocol can make payment easy; the ledger makes overspend visible.

A compact budget ledger entry is enough:

task=research_report_42
budget=0.05 USDC
quoted=0.01 USDC
settled=0.01 USDC
cumulative=0.03 USDC
policy=allow_paid_report_under_budget
next_action=allow_until_0.05

x402 for AI APIs proves the signed payment was accepted under the protocol path, not that the agent's overall spending strategy was sane. The budget ledger is where the operator catches that second category of failure.

Packet Close

x402 for AI APIs should be adopted only when the second request is inspectable. The first request asks for the resource, the 402 response quotes the payment, the policy pause decides whether an agent may spend, the signed retry pays, the facilitator verifies, and the service body still needs validation. The protocol is useful because it makes payment programmable. The implementation is safe only when every packet around the payment is constrained.

The final test is simple: if an operator cannot explain why the agent paid, which exact resource the payment was bound to, which replay controls applied, what the facilitator returned, and why the paid response passed or failed validation, the x402 integration is not ready for autonomous AI spend.

That standard is intentionally stricter than "the API returned 200." x402 for AI APIs moves value through the same path that moves data, so the trace has to explain both.