What x402 is, and why pay-per-call agents matter

HTTP has had a status code for payments since the 1990s. Code 402, "Payment Required," was reserved in the HTTP/1.1 specification for future use, and for roughly three decades that future never arrived. The web built its payment layer elsewhere: merchant accounts, card networks, checkout pages, API keys attached to monthly invoices, all of it designed for humans with browsers and billing departments.

x402 is an open protocol, introduced by Coinbase in 2025, that finally puts the status code to work. The idea is small and precise: let a server charge for a single HTTP request, and let the client pay for it inside the request-response cycle itself, with no account, no API key, and no prior relationship between the two parties.

The mechanics in one exchange

A caller sends a normal request to a paid endpoint. If no payment is attached, the server responds with status 402 and a machine-readable body describing what it accepts: the price, the asset (typically USDC), the network (typically Base, an Ethereum layer-2), and the address that gets paid. The caller's client reads those terms, signs a payment authorization with its wallet key, and retries the same request with the signed x402 v2 payload in a PAYMENT-SIGNATURE header. The server verifies the authorization, settles the transfer on-chain, runs the actual work, and returns the result, usually with a receipt confirming settlement.

POST /api/agents/lead-qualifier/run        → 402 Payment Required
                                              { accepts: [{ amount, asset, payTo, network }] }

POST /api/agents/lead-qualifier/run
  PAYMENT-SIGNATURE: <x402 v2 payload>       → 200 OK
                                              { output, settled: true, transaction }

Two properties of this exchange do the heavy lifting. The wallet is the identity: the caller never registered, never verified an email, never got issued a key. And the payment is the authorization: the server does not need to check a subscription database, because the money either settled or it did not.

Why this matters for agents specifically

For human developers, x402 is a mild convenience; API keys are annoying but workable. For software agents, the difference is structural. An agent that discovers a useful service at runtime cannot fill in a signup form, wait for an approval email, or negotiate a contract. Every step of the traditional API onboarding funnel assumes a person. x402 collapses that funnel into a protocol interaction an agent can complete in seconds: read the payment terms from the 402 response, decide whether the price is acceptable, sign, retry.

Pricing granularity matters just as much. Stablecoin settlement on a cheap network makes a $0.04 call economically viable, a price point card networks cannot express once fixed fees are counted. Per-call pricing at that granularity means an agent can buy exactly one unit of work from another agent, which is the precondition for anything resembling an economy of specialized agents buying from each other rather than a handful of monolithic assistants doing everything badly.

Discovery completes the loop. x402 services conventionally publish their catalog at a well-known URL (/.well-known/x402), listing each endpoint with its payment terms. That gives crawlers, agent frameworks, and other agents a standard place to find what is for sale and what it costs, without a human curating an integration.

What x402 is honestly not

A fair account has to include the limits. x402 is young: the specification, the tooling, and the facilitator infrastructure are all in active development, and conventions that look standard today may shift. Settlement is final: there are no chargebacks, which sellers like and buyers should price into their trust decisions; if an endpoint returns garbage, the protocol does not refund you. Both sides need stablecoin plumbing: the caller needs a funded wallet, the seller needs an address they control, and both inherit the operational realities of holding a digital dollar. And discovery being possible is not the same as demand existing: publishing an endpoint at a well-known URL makes it findable, not popular.

It is also not the right tool for everything. High-value, high-trust transactions want contracts and recourse. Free APIs are already free. x402's sweet spot is the middle: machine-to-machine calls priced in cents, where the cost of onboarding would otherwise exceed the value of the transaction.

How Agent Studio implements it

Suede Agent Studio wraps this protocol so a flow builder never handles the raw mechanics. Publishing a flow creates a crawlable service entry that reports preview, payment-enabled, or unavailable state. A payment-enabled request gets the 402 challenge with exact terms; a valid retry settles USDC on Base before the flow executes. Preview-ready services instead accept an explicit dry-run without payment. Every published service is indexed in the crawlable catalog, while x402 terms appear only when payment is actually enabled. Every settled call routes the full amount to the configured payout address. The honest version of "your agent earns" is "your agent earns when a real call settles."