A growing share of the traffic hitting your API isn't a person clicking through a dashboard — it's an autonomous agent calling you on someone's behalf. That caller has a budget and no patience for a signup form. The old monetization playbook (issue a key, pick a plan, invoice monthly) assumes a human signs up first. Agents don't.
This is the practical playbook for the other model: charge per call, in the request itself, so an agent you've never met can pay and get a result on the spot. No sales call, no provisioning, no billing system to build. Here's how to do it end to end.
Step 1 — Decide what's worth metering
You don't meter everything. Start by separating routes into three buckets:
- Free forever — docs, health checks, marketing endpoints. Leave these open; metering them just adds friction with no upside.
- Already sold to humans — routes behind your existing keys and plans. Keep those as they are. Pay-per-call sits alongside your current billing, not on top of it.
- Worth charging machines for — the endpoints that are expensive to serve or valuable to call: search, enrichment, generation, retrieval, anything compute- or data-heavy.
That third bucket is where per-call pricing earns its keep. The question to ask of each route is simple: if an agent called this a thousand times an hour, would I want that to be revenue or a cost?
Step 2 — Price the call
Per-call pricing is a different muscle than monthly plans. A few rules that hold up in practice:
- Price the value, not your cost. If a single enrichment call saves the caller a real task, a cent or two is trivially worth it to them — and adds up fast for you.
- Keep it legible. Round, predictable prices ("$0.01 per call") are easier for an agent's operator to reason about and budget against than opaque tiers.
- Different routes, different prices. A cheap lookup and an expensive generation shouldn't cost the same. Price each route on its own.
We go deeper on the numbers in how to price an API for AI agents. The short version: start legible, watch real usage, adjust. Because there's no plan to renegotiate, changing a price is a config change, not a customer conversation.
Step 3 — Add one middleware
This is the part developers expect to be hard and isn't. You register the route and its price in the dashboard, get a test or live API key, and add one middleware in your stack. From then on, that route answers an unpaid request with a signed x402 challenge quoting the price; once the agent pays, it serves the result.
There are nine official SDKs sharing one frozen X402v1 wire contract — Express, Next.js, FastAPI, Django, Laravel, Go, Spring Boot, ASP.NET Core, and Rails — so the integration is a few lines, not a project. For example, in Express:
import { x402 } from "@x402/express";
app.get("/enrich", x402({ price: "0.02" }), handler);
Your application code never constructs a challenge, verifies a payment, or touches a wallet. The SDK is a thin client that relays to the platform and fails closed: if it can't verify payment, the route returns a 502 — it never serves paid content for free. Browse the per-stack snippets on the SDKs page.
Step 4 — Prove it for free, then flip to live
You don't pay to find out whether it works. Every account has a test mode: with a sandbox key, the entire challenge → pay → verify → allow loop runs end to end without any real money, so you can wire it into CI and assert the behavior before a single real cent moves.
Going live is one environment variable. The wire format is identical between test and live, so there's no second integration — you flip X402_ENV from sandbox to live and the same code starts accepting real USDC. That free, low-risk first step is the whole point: you get to see the money path work before you commit to it.
Step 5 — Get paid and reconcile
Once you're live, payouts to your wallet are handled automatically — there's no invoicing and nothing to chase. For your own systems, signed and retried webhooks (payment.settled, payout.sent, payout.failed) fire on each event, and a live dashboard shows requests, balances, and payouts per route. Reconciliation is something you read, not something you build.
What you didn't have to do
Step back and notice the work that never appears in this playbook: no key-and-plan provisioning for callers you'll never meet, no metered-billing pipeline, no invoicing, no dunning, no payment or crypto code in your process. The caller pays in the request; you added one middleware. That's the trade pay-per-call makes — it moves the billing complexity off your plate and matches how autonomous callers actually behave.
It's also built on an open standard, not a proprietary middleman: since April 2026 x402 has been governed under the Linux Foundation alongside founding members including Google, AWS, Microsoft, Stripe, Visa, and Mastercard — so the handshake you integrate today is the one the industry is converging on.
Where this fits best
Pay-per-call shines when your callers are autonomous and one-off — exactly the monetize-your-API use case. If your endpoints are data or retrieval, see charging for data & RAG endpoints; if you run an MCP server, see monetizing an MCP server. And if you're weighing this against API keys or card rails, the comparison hub lays out who each option is best for.
Next steps
- See the model end to end: monetize your API for AI agents
- Get the numbers right: how to price an API for AI agents
- Pick your stack: the SDKs
- Check the cost: pricing — free to start, no card
- Ready to wire it up: create an account