x402: The HTTP Status Code That Lets AI Agents Pay

HTTP 402 sat unused for 26 years. x402 activates it so AI agents can pay for APIs mid-request. Here's how it works and how to use it.

Kasra Zunnaiyyer
· 5 min read

TL;DR

  • HTTP 402 (“Payment Required”) was reserved in 1999 and left unused for 26 years because the internet had no native payment layer.
  • x402 activates it. An AI agent hits a paid API, gets a 402 with the price, signs a USDC payment, and retries — all in one HTTP round-trip.
  • No API keys. No billing dashboards. No OAuth. The payment IS the authentication.
  • Over 115 million x402 transactions have settled as of March 2026. This isn’t a proposal. It’s running infrastructure.

The 26-Year Placeholder

In June 1999, the IETF published RFC 2616 — the HTTP/1.1 specification that defined the status codes we still use today. 200 OK. 404 Not Found. 401 Unauthorized.

And 402 Payment Required, with a five-word definition: “This code is reserved for future use.”

That was it. No spec, no flow, no implementation guidance. The internet needed a native payment mechanism that software could operate without human intervention, and nothing like that existed in 1999. DigiCash had filed for bankruptcy the year before. CyberCash needed browser plugins. The web had commerce, but no programmable money.

So 402 sat there. Through every HTTP revision — RFC 7231 in 2014, RFC 9110 in 2022 — same five words. Reserved for future use.

Twenty-six years later, stablecoins and AI agents gave it a reason to exist.

How x402 Works

Coinbase launched x402 in May 2025. Cloudflare co-founded the x402 Foundation four months later. The protocol is simple — deliberately so.

The full flow:

  1. Agent requests a resource. Standard HTTP — GET https://api.weather-data.com/forecast/NYC.
  2. Server responds 402. The response includes a PAYMENT-REQUIRED header containing the price, accepted token (USDC), blockchain network (Solana), and the merchant’s wallet address.
  3. Agent reviews the price. Its wallet checks balance, guard rails, and spending limits.
  4. Agent signs a payment. A USDC transaction is signed on Solana — sub-second, costs around $0.00025.
  5. Agent retries with proof. Same request, now with a PAYMENT-SIGNATURE header containing the signed payment.
  6. Server verifies and delivers. Payment settles on-chain. Server returns 200 OK with the data, plus a PAYMENT-RESPONSE header confirming settlement.

Three headers. One round-trip. No accounts, no sessions, no API keys.

The key insight: the payment itself is the credential. An agent that can pay is an agent that’s authenticated. No signup flow required.

Note

x402 is blockchain-agnostic — it supports Base, Ethereum L2s, and Solana. Botwallet agents transact in USDC on Solana, where sub-cent micropayments are economically viable at $0.00025 per transaction.

What This Looks Like From the Agent’s Side

Most x402 explainers describe the protocol from the server’s perspective. Specifications and flow diagrams. Here’s what it actually feels like when an AI agent uses it.

Discover Available APIs

Agents don’t need to know API URLs upfront. They can browse:

botwallet x402 discover "weather"

This returns a catalog of x402-enabled APIs, searchable by keyword. Each listing includes the endpoint, pricing, and what data it provides. For the broader ecosystem beyond the curated list:

botwallet x402 discover --bazaar

Probe Before You Pay

This is the part most explanations skip. An agent doesn’t have to commit to paying the moment it sees a price. It can window-shop.

botwallet x402 fetch https://api.weather-data.com/forecast/NYC

If the API is free (200 response), the agent gets the data immediately — no payment, no step two. If the API requires payment (402 response), the agent sees the price and gets a fetch_id. No money moves.

The agent can probe multiple APIs, compare prices, and commit only when ready. Guard rails are checked at this stage too. If the price exceeds the agent’s per-transaction threshold, the response says awaiting_approval and the human owner gets notified before any money leaves the wallet.

{
  "fetch_id": "txn_8f2a...",
  "status": "pre_approved",
  "url": "https://api.weather-data.com/forecast/NYC",
  "amount_usdc": "0.05",
  "fee_usdc": "0.01",
  "total_usdc": "0.06",
  "next_step": "confirm",
  "confirm_command": "botwallet x402 fetch confirm txn_8f2a..."
}

Pay and Get Data

Once the agent decides to proceed:

botwallet x402 fetch confirm txn_8f2a...

This triggers FROST 2-of-2 threshold signing — the agent holds one key share, the Botwallet server holds the other. Neither can sign alone. The signed transaction goes to the API server as proof of payment, and the data comes back.

Probe, decide, sign, pay, receive. Under two seconds.

Tip

Smart agents call botwallet x402 fetch on multiple providers before committing. A weather forecast that costs $0.05 from one API might cost $0.02 from another. The probe step is free — use it.

Why This Replaces the Old Model

Before x402, an AI agent that needed data from a paid API had two options:

Shared API key. The developer pre-provisions a key, stores it in the agent’s environment, and hopes the agent doesn’t leak it via prompt injection or a bad plugin. No per-request spending control. No audit trail per agent. One compromised agent means rotating keys for every agent on that key.

Human in the loop for every API. The agent requests data, the human signs up, enters a credit card, gets a key, and passes it to the agent. For every API. Every time. At 3 AM when the agent discovers a new data source it needs.

Both models collapse when agents need dozens of data sources — some discovered at runtime, some used once and never again. You can’t pre-provision keys for APIs you don’t know exist yet.

x402 removes both problems. The agent pays per-request, from its own wallet, under its owner’s guard rails. No pre-provisioned credentials. No human creating accounts. The agent encounters a paid API, checks the price, and either pays or asks permission.

APIs stop being pre-negotiated contracts. They become vending machines. Put in the coin, get the product.

Guard Rails Apply Here Too

x402 payments don’t bypass spending controls. Every botwallet x402 fetch passes through the same guard rail system as regular payments:

ControlHow It Applies to x402
Per-transaction thresholdAPI prices above this amount require owner approval before the agent can confirm
Daily budgetx402 spending counts toward the daily total — hit the budget and every subsequent API call needs approval
Hard capAPI prices above this are blocked outright, no approval flow
Recipient firewallWhen enabled, only payments to approved API providers auto-approve

The agent can check its remaining budget before probing:

botwallet limits

No surprises. The agent knows its boundaries before spending a cent. If you haven’t set up a wallet yet, the agent setup guide takes about five minutes.

115 Million Transactions and Counting

x402 has processed over 115 million transactions as of March 2026, with adoption growing 10,000% in a single month during its early ramp. Coinbase and Cloudflare co-founded the x402 Foundation to advance the open standard. The protocol is public. Any server can implement a 402 response. Any wallet that can sign on a supported blockchain can pay. It’s one of the core payment layers powering what’s now called the agent economy — agents transacting with services, and with each other, at machine speed.

What’s happening now is what the IETF imagined in 1999 — an internet where software pays for access as naturally as it requests a page. It just took 26 years for the payment rails to catch up.

The status code was always there. The infrastructure wasn’t. Now it is.

Frequently Asked Questions

What is the x402 protocol?
x402 is an open protocol that activates the HTTP 402 status code for real payments. When an AI agent requests a paid API, the server responds with 402 and payment details. The agent signs a USDC transaction and retries the request with proof of payment. The entire flow completes in under a second.
How does an AI agent pay for an API using x402?
The agent sends a normal HTTP request. If the API requires payment, it gets a 402 response with the price. The agent's wallet signs a USDC transaction on Solana and resends the request with a PAYMENT-SIGNATURE header. The server verifies payment and delivers the data.
Does x402 work with any blockchain?
x402 is blockchain-agnostic by design, but most implementations use USDC on Solana or Base. Botwallet agents pay via Solana USDC, where transaction costs are around $0.00025 — making even sub-cent micropayments economically viable.
Can I set spending limits on x402 API purchases?
Yes. With Botwallet, x402 purchases go through the same guard rails as any other payment. Per-transaction caps, daily budgets, and recipient firewalls all apply. Your agent can also probe API prices without paying using the preview flow.
Share

More from the blog