How to Charge AI Agents Per Call: Building a Pay-Per-Call API

What changes when the buyer is software

Traditional API commerce assumes a purchasing process: someone evaluates, signs up, receives a key, and is invoiced. Everything about your onboarding, documentation, and support exists to serve that human.

Agent buyers skip all of it. There is no evaluation period, no signup, no key. A program encounters your endpoint, reads the price, decides, pays, and consumes. Possibly once and never again.

That has three consequences worth designing for.

Your pricing has to be machine-readable rather than persuasive. A pricing page written to convince a buyer is useless when the buyer is parsing fields.

Your error responses become part of the product. A human developer reads docs and asks support. An agent reads your error text and acts on it, so a vague message produces a wrong retry rather than a support ticket.

And you lose the relationship you would normally use to manage abuse, communicate changes, and understand demand. Attribution has to come from telemetry rather than from accounts.

The server side flow

Quote. An unauthenticated request returns 402 with structured terms: amount, asset, network, destination, and an identifier that binds this quote to this request. Keep quotes short lived and explicit about expiry, since prices that never expire are prices you cannot change.

Verify. The retried request arrives with proof. Verification must be fast and cheap, because it happens on every call rather than once per contract. Cache what you can, and make sure a verification failure returns a specific reason rather than a generic rejection.

Serve, then record. Deliver the response and record the payment against the request identifier, the resource, and the price. That record is your only view of who bought what, since there are no accounts.

Handle the failure case. If you accept payment and then cannot serve, decide in advance: refund automatically, issue a credit tied to the request identifier, or serve later. Whatever you choose, say it in the 402 terms. Agents cannot infer your goodwill.

Idempotency, because agents retry

Assume every request will be retried, sometimes after payment and before the response arrives. This is not an edge case with automated clients, it is normal traffic.

The rule that prevents double charging is to bind payment to a request identifier issued in the quote. When a retry arrives carrying an existing proof for that identifier, serve the response rather than requiring a new payment. That means storing the mapping from identifier to payment and to the result you produced.

It also means deciding how long you honor a paid identifier. Too short and a client that reconnects after a network failure pays twice for one answer, which they will notice and remember. Too long and you carry storage plus a replay surface. A window measured against your own latency is usually the right frame.

The failure to design this is the most common way a working demonstration becomes an unhappy production integration, because the symptom is duplicate charges rather than an error, and duplicate charges are what buyers escalate.

Being paid, and being paid safely

Settlement should land in an asset you can account for, on a network where confirmation is fast enough to serve inside a request and cheap enough that fees do not consume small sales. In practice that means a stable settlement asset on a low-cost network rather than a volatile token, because a price quoted in something that moves is a price neither side agreed to.

On the buyer side, the agents you want as customers need bounded spending authority, and the ones without it are the ones that generate disputes and abandoned payments. CryptoCadet is that half of the market: a non-custodial USDC rail on Base where an agent spends from a session-key bounded float with custody in the OS keychain, supporting x402-style pay-per-call and ERC-20 subscriptions. For a seller, the practical benefit is that payments arrive in USDC on Base with fast finality, from clients whose spending limits are enforced rather than promised.

If your pricing suits ongoing access rather than discrete calls, subscriptions are the better instrument. Metering every call is the correct model for unpredictable, bursty consumption. It is the wrong model for a client that wants continuous access and predictable cost, and offering only one of the two narrows your market unnecessarily.