Before you set a single price, you have to decide what to charge for. Metering the wrong routes adds friction that earns nothing; leaving the valuable ones open leaves money on the table. This is the decision framework.
Quick answer: Sort your routes into three buckets — free forever (docs, health checks, auth, cheap discovery), already sold to humans (keep on your existing keys and plans), and worth charging machines for (expensive-to-serve or high-value endpoints: search, enrichment, generation, retrieval). Only meter the third bucket, and price it per route. The test for any endpoint: if an agent called it a thousand times an hour, would you want that to be revenue or a cost?
The three buckets
Every route on your API falls into one of these:
- Free forever. Documentation, health checks, status, auth handshakes, marketing endpoints, and cheap discovery calls. Metering these adds friction with no upside — and free routes do real work: they let an agent discover and trust your API before it pays for anything.
- Already sold to humans. Routes behind your existing API keys and subscription plans. Leave them exactly as they are. Pay-per-call sits alongside your current billing, not on top of it — you're adding a payment path for machines, not migrating your customers.
- Worth charging machines for. The endpoints that are expensive to serve or valuable to call: search, enrichment, generation, retrieval — anything compute- or data-heavy. This is the only bucket you meter.
The test for each route
For any endpoint you're unsure about, ask one question:
If an autonomous agent called this a thousand times an hour, would I want that to be revenue or a cost?
If the honest answer is "revenue," meter it. If it's "cost I'd absorb to be helpful" (docs, discovery), keep it free. If it's "that's what my paying customers already do," it belongs on your existing plans. The question cuts through most of the ambiguity because it forces you to price the behavior, not the endpoint in the abstract.
What to keep free — on purpose
Free routes aren't just the leftovers. They're how an agent finds and trusts you:
- Discovery — an agent has to be able to look before it pays. A free "what can this API do" call is a sales surface, not lost revenue.
- Cheap-to-serve calls — if a route costs you nothing and isn't especially valuable, charging for it buys friction, not margin.
- Anything a human relies on for free today — don't break existing free behavior to chase pennies from agents.
The goal is a clean split: free where openness helps you, priced where the work is real.
What to meter
The routes worth charging machines for share a shape — they cost you something to serve, or they're worth something to the caller:
- Search and lookup at scale, where volume is the cost.
- Enrichment — turning an input into something more valuable (a scored lead, resolved company data).
- Generation and RAG — synthesized answers, rendered artifacts, retrieval over your data. See monetizing a data or RAG API.
- Anything compute- or model-backed, where each call has a real marginal cost you need to clear.
Price each of these per route, not one number for the whole API — a cheap lookup and an expensive generation shouldn't cost the same. See how to price an API for AI agents and the 2026 benchmarks.
Don't meter humans by accident
A practical guardrail: metering with x402 targets the routes and callers you choose. Real people browsing your product, and developers on your existing plans, are unaffected — you're adding a 402-priced path for machine traffic on specific endpoints, not putting a tollbooth in front of everyone. Start the priced routes in test mode and confirm your free and authed routes still behave before you go live.
FAQ
Which API routes should I charge for? The ones that are expensive to serve or valuable to call — search, enrichment, generation, retrieval. Keep docs, health checks, auth, and cheap discovery free, and leave routes you already sell to humans on their existing plans. Use the test: if an agent called this a thousand times an hour, would you want revenue or a cost?
Should I meter my whole API? No. Metering everything adds friction to routes that earn nothing and can break free behavior humans rely on. Meter only the expensive or high-value endpoints, and price each per route.
Will charging for some routes affect my human users or existing customers?
No. A 402-priced path applies to the routes and callers you choose; real people and developers on your existing keys and plans are unaffected. Confirm it in test mode before going live.
Do I keep my subscriptions if I add pay-per-call? Yes. Per-call pricing sits alongside your existing keys and plans, not on top of them — subscriptions for known human integrations, per-call for agent traffic. See add pay-per-call to an existing API.
Next steps
- Set the price: how to price an API for AI agents
- The model end to end: the monetization playbook
- What you don't have to build: billing infrastructure to charge per API call
- Try it free: pricing and create an account