x402: How AI Agents Pay for APIs Without an Account

Every API on the internet is sold through a form.

You land on a pricing page, type an email, confirm it from an inbox, paste a card, copy a key, and store it in an environment variable. It takes four minutes and it works fine — because you are a human, and humans have inboxes, cards and patience.

Now picture an AI agent halfway through a research loop. It needs one web page converted to Markdown, right now, to finish the task it was given. It cannot receive a confirmation email. It has no card. It cannot wait for a human to wake up and paste a key.

So it does the only thing left: it gives up and uses something else.

That gap is what x402 closes, and as of today the Minibase API answers it in production.

HTTP had a plan for this in 1997

Status code 402 Payment Required has been in the HTTP spec since the beginning, marked “reserved for future use.” For nearly thirty years it stayed a joke in the RFC — the status code nobody could implement, because the web had no way to move small amounts of money inside a request.

x402 is the protocol that finally uses it. The shape is simple enough to explain in three steps:

1. A client calls your endpoint with no credentials at all.
2. Instead of 401 Unauthorized, the server answers 402 Payment Required and attaches machine-readable payment terms — how much, in what asset, on what network, to which address.
3. The client pays and repeats the request with proof of payment attached. The server verifies, settles, and serves the response.

No account. No key. No dashboard. The entire negotiation happens inside two HTTP round trips, in a format another program can read.

What it looks like on a live endpoint

Call our conversion endpoint with nothing:

curl -i -X POST https://api.minibase.md/v1/convert \
  -H "Content-Type: application/json" \
  -d '{"url": "https://example.com/article"}'

You get a 402, and the terms come back base64-encoded in a payment-required header:

{
  "x402Version": 2,
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:8453",
    "amount": "10000",
    "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
    "payTo": "0xfb8157a583e3050440301f418f5e890190222a5c",
    "maxTimeoutSeconds": 300
  }]
}

Everything an autonomous client needs is in there. network is a CAIP-2 identifier — eip155:8453 is Base mainnet. asset is the USDC contract. amount is atomic units: USDC carries six decimals, so 10000 is one cent. payTo is where the money goes.

The client signs a USDC transfer, retries with the payment attached, and gets its Markdown back. Total human involvement: zero.

The part nobody mentions: you don’t have to hold crypto

The obvious objection to any “accept stablecoins” pitch is that you now run a wallet. Private keys. Custody. A balance denominated in something your accountant has never seen, valued at a rate that moved while you were asleep.

We don’t do any of that, and neither do you have to. The deposit address in the payload above was issued by Stripe. Payments settle on-chain to that address, Stripe records each one as an ordinary PaymentIntent, and pays out in EUR on the normal schedule.

The practical consequence is that the money shows up in the same dashboard as every card payment, on the same payout, in the same books. There is no wallet to secure, no foreign-currency valuation per receipt, no separate ledger to reconcile at year end. The stablecoin part is real, and it is also entirely invisible from the accounting side.

Two things that cost us time

If you are implementing this yourself, here are the two traps we paid for.

The facilitator handshake is not optional. A resource server has to ask the facilitator which scheme and network pairs it actually settles before it can quote anything. Skip that step and every single call dies with Facilitator does not support exact on eip155:8453 — a message that reads like a configuration error and is really a missing round trip. On mainnet, that facilitator is Coinbase’s; the public testnet one does not settle real money.

Sub-cent pricing quietly breaks your bookkeeping. Our cost model is roughly $0.002 per page, so pricing the x402 door at $0.002 looked obvious. It is not: PaymentIntents are denominated in integer cents, so anything below one cent settles on-chain and then cannot be recorded at all. The money arrives and enters no book. We price the keyless door at $0.01 per call for exactly this reason — five times our volume rate, which pay-per-call with no account and no commitment carries comfortably.

Should you add it?

Be honest about the size of it: x402 is not going to replace your subscription revenue this quarter. Agent-initiated payments are early, the client tooling is young, and most of your customers are still humans with cards.

But the asymmetry is unusual. Adding the door cost us a few hundred lines and it fires only for callers presenting no credential at all — every existing key holder falls straight through to the path they already had, with the same quota and the same plan. Nothing you already sell is at risk.

And the failure mode of not having it is invisible. A keyless caller that hits a 401 leaves no trace, no signup, no support ticket, no line in your analytics. You never learn it was there. We instrument that specifically now — every keyless call is logged with whether the caller already speaks the protocol — because “is anyone knocking?” is the only question that decides whether any of this was worth building.

If agents are going to buy things on the open web, they need a way to pay that does not route through a signup form. That way already exists, it has been sitting in the HTTP spec since 1997, and it takes an afternoon to wire up.

---

Try it: call POST https://api.minibase.md/v1/convert with no credentials and read the payment-required header. Prefer a key? The free tier is 1,000 pages a month, no card. Full spec for agents: minibase.md/api.md.