x402 explained: how AI agents pay for APIs
HTTP-native machine payments, from first principles.
HTTP status code 402 — "Payment Required" — has been reserved since 1999, sitting dormant in the spec as a placeholder for "future use." Twenty-seven years later, it's finally being put to work.
The x402 protocol turns that status code into a machine-readable payment negotiation. When a client calls an API and gets a 402 response, the response body contains structured payment instructions — which token, which network, how much, and where to pay. A compatible client (or AI agent) can read those instructions, execute a payment, and retry the request with proof of payment attached.
Why this exists
Traditional API billing works fine for human developers. You sign up, enter a credit card, get an API key, and your usage is tracked against a billing account. But this model breaks down for autonomous AI agents.
An agent running inside a framework like OpenClaw, LangChain, or CrewAI can't fill out a signup form. It can't enter credit card details. It doesn't have a Stripe billing account. For an agent to use a new API, a human has to manually provision access — defeating the point of autonomy.
x402 eliminates this bottleneck. An agent discovers an API (via agents.txt, llms.txt, or web search), calls it, and if it requires payment, the agent pays and proceeds. No human intervention, no pre-provisioned credentials.
The protocol flow
Step 1. The agent sends a normal API request — no auth header, no payment.
Step 2. The server responds with 402 Payment Required and a JSON body describing the accepted payment schemes. This includes the blockchain network (e.g., Base), the token (e.g., USDC), the amount, and the recipient address.
Step 3. The agent's x402 client reads the payment details, signs a payment (typically an EIP-3009 authorisation for USDC), and constructs a payment proof.
Step 4. The agent re-sends the original request with an X-PAYMENT header containing the base64-encoded payment proof.
Step 5. The server verifies the payment on-chain, processes the request, and returns the result.
The entire flow happens in a single roundtrip (two HTTP requests). For the agent, it looks like calling a normal API that happens to cost money.
Why USDC on Base?
Micropayments need two things: a stable unit of account (so $0.005 means $0.005, not $0.003 tomorrow) and low transaction fees (so paying half a cent doesn't cost $2 in gas). USDC on Base delivers both. USDC is a dollar-pegged stablecoin, and Base is an Ethereum L2 where transaction fees are fractions of a cent.
What this means for API builders
If you're building an API, adding x402 support means your API is immediately accessible to the growing population of AI agents. You don't need to build agent-specific auth flows, manage agent accounts, or worry about agent billing. The agent pays per-request, the payment settles on-chain, and you receive USDC in your wallet.
It's also a signal. APIs that support x402 are discoverable via agents.txt and llms.txt — the emerging standards for machine-readable API directories. An agent searching for "screenshot API" will find your API not through Google, but through these structured discovery files.
Getting started
If you're an API builder, the x402 npm package and Python SDK handle the server-side verification. If you're an agent builder, those same packages handle the client-side payment flow.
nightglass uses x402 as its default payment path — calling the screenshot endpoint without an API key triggers the x402 flow automatically. It's a working example of the pattern in production. See the agent payments docs for the full implementation details.
For the bigger picture on agent-native commerce, see the rise of agentic commerce. For how agents discover APIs in the first place, see agents.txt and llms.txt: making your API discoverable. For a practical example in a screenshot API, the API comparison explains why agent access is the differentiating feature heading into 2027.