Skip to main content
Most software cannot buy anything. It can be given a key by a human who signed up, agreed to terms, and put a card on file — but the software itself has no way to see a price, decide it is worth paying, pay it, and get the thing. Otto AI exists on the other side of that line. An agent can look at what Otto sells, see the price before committing, pay for exactly one request, and receive the result — with no account, no key, and no human in the loop. This page walks through one purchase, end to end, in plain English. If you want to run it yourself, the Agent Quickstart is the same flow with working code.

The whole purchase, in five moves

Everything shown below is real. The response excerpts are taken verbatim from live calls against the production catalog, abridged only for width.

1. The agent asks for something

It makes an ordinary web request. No key, no token, no prior relationship.

2. Otto answers with the price, not the data

The server replies 402 Payment Required — a status code that has been in the HTTP specification since the beginning and sat unused for decades. It is not an error. It is a quote.
The long header is the machine-readable half. Decoded, it is the whole offer:
Read it as: pay 5,000 units of this token, on this network, to this address. The asset is USDC on Base, and USDC has six decimal places — so 5000 is half a cent. Nothing is hidden and nothing is negotiated after the fact. The agent knows the price before it spends anything.

3. The agent signs a payment and asks again

The agent signs a payment authorization locally with its own wallet and repeats the same request, this time carrying the proof. The key never leaves the agent’s machine, and Otto never holds a balance on the agent’s behalf. Two things surprise people here:
  • No gas is needed. The payment is a signed authorization; the settlement layer submits the on-chain transaction and covers the gas. The agent’s wallet only needs the stablecoin it intends to spend.
  • Nothing is created. No account row, no tenant, no key. The wallet that signed is the identity, for exactly as long as the request takes.

4. Otto delivers the result

The retried request returns 200 OK with the data the agent asked for. That is the entire transaction — one request that was quoted, one that was paid.

5. The receipt comes back in the response

The paid response carries an X-Payment-Receipt header holding the on-chain transaction hash of that payment. It is a public record on Base that anyone can look up, and it is the credential for everything that happens afterwards.

What this purchase produced

1 on-chain payment · 1 delivered result · 1 verifiable receiptAccounts created: 0 · API keys issued: 0 · Subscriptions started: 0 · Invoices sent: 0 · Emails exchanged: 0
The absence is the point. Every one of those zeros is a step a human normally performs on software’s behalf, and none of them happened.

What the receipt is actually for

The receipt is not a formality. It is how Otto AI ties everything else to a payment that provably occurred.

Feedback that means something

Send the receipt’s transaction hash with a verdict, and Otto records it. There is no account to create and no form to fill in — the receipt is the credential, so only someone who actually paid can rate the call.

A money-back guarantee

Add a reason of at least 50 words and Otto refunds the fee in USDC, to the original payer address and nowhere else. Capped at $0.01 per transaction and never more than you actually paid.
The guarantee is deliberately bounded, and the bounds are published rather than buried: Full terms, including how to claim, live on the Otto X402 Router page.

When the agent does not know what to buy

The flow above assumes the agent already knows which service it wants. Often it does not — it has a question, not an endpoint. For that, one request describes the need and the Router answers with the best-matched services, each with its real price and a ready-to-call address, drawn from both Otto’s own catalog and the live public marketplace. Otto only recommends; the agent pays each service directly. Or the agent can hand over the whole errand: Full Auto picks the best-matched service, pays it at cost on the agent’s behalf plus a flat $0.001 routing fee, and returns the data — within a spending cap the caller sets, with no prepaid balance held anywhere. See the Otto X402 Router.

Three rails, one swarm

The purchase above ran on x402, Otto AI’s canonical HTTP rail. It is not the only way to buy, because not every buyer wants the same shape of transaction. The differences below are structural, not marketing tiers. Three honest caveats, because rail comparisons are where documentation usually starts flattering itself:
  • The counts are not meant to match. Each rail is a deliberately different curated catalog, not an incomplete copy of x402. A capability missing from one rail is usually a policy decision, not a gap.
  • x402 is the canonical surface. If you are choosing without a constraint pushing you elsewhere, choose x402.
  • There is a fourth surface. Otto X is a separate agentic-wallet product on X Layer with its own custody model, which is why it is not a column here.
For the capability-by-capability breakdown — which exact service is reachable on which rail — see Access Paths & Coverage, which is generated from the same catalog sources these counts come from.

Frequently asked, honestly

402 Payment Required has been reserved in the HTTP specification since it was written. What was missing was an agreed way to say what to pay and how — which is what the x402 protocol adds, on top of the status code that was always there. Otto AI implements it; Otto did not invent it.
No. Payments are signed by your own wallet, per request, for the exact quoted amount. Otto does not hold a prepaid balance for you and cannot charge you for something you did not request. Full Auto spends on your behalf only within a cap you set on that call.
Two things, and neither is a promise. The payment is tied to a specific request, and the response carries a receipt you can check on-chain. If the result is not what you paid for, that same receipt is what backs a refund claim, within the published caps above.
Yes, but it is not the point. The catalog is browsable and every service is documented, though the experience is built for software making its own purchasing decisions. If you want a human interface to Otto AI, use the app rather than the payment rails.
Every rail publishes machine-readable descriptions of itself — a text catalog, an OpenAPI description, and payment metadata at a well-known address. Point an agent at https://x402.ottoai.services/llm.txt and it can enumerate the whole catalog with prices, unaided.

Next

Agent Quickstart

The same flow with working code — from an empty folder to a first paid result.

The x402 catalog

Every endpoint, what it returns, and what it costs.