How to add pay-per-call to an existing API without breaking your customers

Most advice about charging AI agents assumes a greenfield API. Yours isn't. You have real customers with API keys, plans they pay monthly, and integrations you can't afford to break. Now agents are showing up too, and you'd like to charge them — but not at the cost of the customers who keep the lights on. The good news: you don't have to migrate anything. You add a lane. This post is how to do that safely.

How do you add pay-per-call to an existing API? Keep your current authentication and billing exactly as they are, and add an x402 path alongside them: on the routes you choose, a request with a valid existing credential is served as it is today, and a request without one gets a signed 402 with a price that agents can pay per call. Existing customers notice nothing; agents get a way in that never existed before.

The principle: add a lane, don't migrate

"Migration" is the wrong frame. It implies moving customers from one system to another, with a deprecation deadline and a support burden. You don't want that — your API-key customers are fine where they are. What you want is a second lane on the same road: the existing lane for known customers with credentials, and a new lane for autonomous callers who pay per request.

The two lanes coexist on the same routes because they answer different questions. The existing lane asks "who are you, and are you within your plan?" The agent lane asks "did you pay for this call?" A request takes whichever lane it qualifies for.

The coexistence pattern

Concretely, the agent lane sits behind your existing auth check. On a route you want to open to agents, you check for a valid existing credential first; if it's there, serve exactly as you do today; if it isn't, hand the request to the x402 gate:

// Two lanes on one route
app.get("/api/data",
  (req, res, next) => {
    if (hasValidApiKey(req)) return next();   // existing customer → serve as today
    return x402Gate(req, res, next);          // no credential → agent lane: 402 + price
  },
  serveData
);

x402Gate is the SDK middleware for your stack; hasValidApiKey is your existing auth. The composition is yours, which is the point — you decide exactly when the agent lane applies, per route. Routes you don't touch keep behaving as they always have. (For why keys and per-call payments answer different problems in the first place, see x402 vs API keys.)

A phased rollout that can't break anything

The safe path adds the lane incrementally and proves each step before widening it.

1. Pick a few routes, not all of them. Start with the endpoints agents actually want and that are worth metering — your high-value, frequently-scraped data or actions — not your whole surface. Your login route doesn't need a price.
2. Put the agent lane behind your existing auth. Use the coexistence pattern above so a valid customer credential always short-circuits to today's behaviour. This is the step that guarantees existing customers are untouched.
3. Prove both lanes in sandbox. Assert that a request with a valid key serves as before, and a request without one returns a 402 with the right price. Run it in test mode with synthetic settlement so no real money moves — see how to test x402 payments. This is where you catch a mis-scoped auth check before it reaches production.
4. Go live on the subset, watch the signals. Flip those routes to live, and use webhooks and per-route attribution to see which endpoints agents actually pay for. You're now earning on traffic that used to be free or blocked, with zero change to existing revenue.
5. Expand where it pays. Add the lane to more routes as the data tells you where agent demand is. You're never forced into a big-bang cutover.

What not to do

A few failure modes worth naming, because they're the ways this goes wrong:

• Don't rip out API keys. Per-call payment is a complement, not a replacement. Your long-lived integrations with known customers are exactly what keys and plans are good at. Keep them.
• Don't force existing customers onto per-call. They didn't ask for it, and it changes their budgeting. New callers opt into the agent lane by not having a credential; existing ones stay where they are.
• Don't gate your whole API on day one. Meter the routes worth metering. Over-gating creates support load and risks catching a customer you meant to leave alone.
• Don't drop your rate limits. They still protect you — from both lanes. A paying agent shouldn't be able to hammer you unbounded any more than an abusive key holder. Per-call payment and rate limiting do different jobs; keep both.

Pricing the agent lane

Because existing customers are unaffected, you can price the agent lane on its own terms — per call, in proportion to the work the route does. Start near your marginal cost, make the price visible in the 402 challenge so agents can decide, and raise it where demand proves the value. The full method is in how to price an API for AI agents; the short version is that the agent lane is a clean pricing experiment you can run without renegotiating anything with the customers you already have.

A note on "aren't my automated customers also agents?"

Some of your existing customers call your API from scripts and services — automated, but not the anonymous autonomous agents this is about. The distinction is simple: they have a credential and a relationship. They keep taking the existing lane; nothing about adding an agent lane changes that. The agent lane is specifically for the callers who don't have an account with you and would otherwise be blocked or served for free.

FAQ

Do I have to remove API keys to support agent payments? No. Add the x402 lane alongside your existing keys and plans. A request with a valid credential is served as it is today; only requests without one take the pay-per-call path.

Will this affect my current customers? Not if you put the agent lane behind your existing auth check, so a valid credential always short-circuits to today's behaviour. Existing customers keep their keys, plans, and exact experience.

Which routes should I open to agents first? The high-value endpoints agents want and that are worth metering — not your whole API. Start with a few, prove them in sandbox, then expand where demand shows up.

How do I test this without risking production? Run both lanes in sandbox with synthetic settlement: assert that a valid key serves as before and a missing credential returns a 402 with the right price. Only then flip the subset to live.

Can I price the agent lane differently from my plans? Yes — the agent lane is per-call and independent of your existing plans, so you can price it on its own terms without changing anything for current customers.

Next steps

• The reasoning behind two lanes: x402 vs API keys
• Set the agent-lane price: how to price an API for AI agents
• Prove both lanes safely: how to test x402 payments
• See what agents pay for: handling x402 payment webhooks
• Add the lane, per stack: the nine SDKs · create an account