How to Charge AI Agents for API Access When They Have No Account

Short answer: You have three options for charging an AI agent that calls your API. Issue it a scoped API key tied to a prepaid balance, which works when the agent belongs to a customer you already have. Sell through a marketplace that handles identity and payment for you, which costs you a revenue cut and the customer relationship. Or return HTTP 402 Payment Required with a price, and let the agent pay for that single call using the x402 protocol, which is the only option that works for a caller who has never signed up and never will. Most APIs should run the first and third side by side.

Why API keys break when the caller is an agent

Every commercial API in production assumes a sequence: a developer discovers the docs, creates an account, confirms an email, generates a key, pastes it into their code, and starts calling. That funnel took decades to standardize and it works well, because a human integrator is patient. They are building something that will run for years, so waiting an afternoon for approval is not a real cost.

An agent is not patient, because it is not building anything. It is executing one task, right now, and your API is a means to finish it. If the answer to "can I have this data" is "create an account and wait", the agent does the same thing a person does when a paywall appears mid-search: it leaves and finds another source. You never see the request, so you never learn you lost it. That is the uncomfortable part of agent traffic. It fails silently, and your analytics show nothing at all rather than a drop-off you could act on.

There is a second problem underneath the first. Even if an agent could sign up, monthly invoicing against an unsecured account is a genuine credit risk when the caller can go from zero to a hundred thousand requests in an afternoon because somebody edited one line of a prompt. Human integrators ramp over weeks. Agent fleets do not ramp.

The three ways to charge an agent, compared

These are not mutually exclusive, and the sensible end state for most APIs is the first and third together.

How to add per-call payment to an API you already run

The mechanics are smaller than most teams expect, because the x402 protocol deliberately does very little. Your server keeps doing its job and gains one new response shape.

1. Pick the routes worth charging for. Not everything should cost money. Health checks, docs and cheap metadata lookups are better left free, because they are how an agent discovers what you sell.
2. Answer unpaid requests with 402. The body is a small JSON document naming the price, the asset, the chain and the address to pay. An agent reads the price out of the error rather than out of your docs, which is the entire trick.
3. Verify before you do the work. When the agent retries with a signed payment attached, hand that payload to a facilitator and ask whether it is valid and funded. If you skip this, you are doing paid work for free on every malformed request.
4. Settle after the work succeeds. The seller carries a small window of risk here, which is deliberate: it means the buyer is not waiting on a block confirmation to get their response.
5. Return a receipt header alongside the resource, so the caller can reconcile what it spent.

Whether you run your own facilitator or use a hosted one is a real decision with cost and latency consequences, and we walk through it in what an x402 facilitator does and when to self-host.

How should I price a call an agent makes?

Price the same way you would for a human customer, then check one extra thing: whether the price survives being called in a loop. Agents retry. A price that is reasonable at ten calls a day can be alarming at ten thousand, and if your margin depends on callers being sensible, you do not have a margin.

Per-call pricing suits APIs where a single call carries obvious standalone value: a lookup that returns a record, a document parsed, a query answered against an index. Data services fit this shape especially well, which is why so much of the early agent-payable traffic is going to things like a fully indexed on-chain data API where one query is genuinely one unit of value. If your call triggers an LLM instead, price in tokens or credits rather than requests, because request count stops tracking your cost the moment prompt sizes vary. The full breakdown of models sits on our API monetization page.

What about rate limiting and abuse?

Payment is not a substitute for rate limiting, and treating it as one is the most common mistake here. A paying caller can still overwhelm you, and a payment that clears does not mean the request was legitimate. Keep your existing limits and add a second layer keyed on the paying account rather than the IP or the key, since an agent that pays per call has no key to key on. The useful property is that abuse now has a cost attached, which changes the economics of scraping you far more than a 429 ever did.

Do I have to accept stablecoins?

For x402 specifically, yes: settlement is an on-chain transfer, typically USDC, and you need somewhere to receive it. That is a real operational decision involving treasury, accounting and your finance team, not a technical footnote, and it is the honest reason many teams stop here. What it buys you is the ability to accept payments far too small for card rails, where a fixed authorization fee dwarfs a payment worth a fraction of a cent. If your calls are worth dollars rather than fractions of cents, the economics are less compelling and a prepaid balance on an API key may serve you better.

The calculation shifted in August 2026, because the buy side is now managed for a large set of callers. Amazon Bedrock AgentCore Payments went generally available on August 18 and gives agents built on AWS a stablecoin wallet that settles x402 and MPP charges without any integration work on their end. If your customers are building on that stack, accepting x402 stops being a bet on a protocol and becomes meeting them where their payment method already is. Our page on AWS AgentCore spend controls covers what that wallet can and cannot do, including the fact that it reaches no card rail at all.

Should I keep my API keys?

Yes. The framing that works is that keys serve the customers you have a contract with, and 402 serves the callers you never will. Enterprise buyers want an invoice, a signed agreement and a named account manager, and none of that is improved by per-call settlement. Running both means a large customer gets the commercial relationship they expect while an unknown agent can still buy one call at three in the morning. Turning off keys to chase agent traffic would trade revenue you can forecast for revenue you cannot.

The mirror image: what your own agents spend

Teams that ship a paid API usually meet the other half of this problem within a quarter. You now meter every inbound call precisely, while your own agents call other people's paid endpoints with no equivalent discipline. Per-call pricing is excellent when you are selling and genuinely risky when you are buying, because nothing in a 402 response knows how much your agent has already spent this hour. A retry loop against a mispriced endpoint finds the bottom of a prepaid wallet faster than most alerting finds the loop.

Budgets belong to the payer, not to the payment, so the control has to sit above the rail: a hard per-agent budget, a per-vendor cap, an approval threshold above which a person is asked, and a record tying every settled payment back to the agent and the task behind it. That is what agent spend controls are for, and the same console lets you take payments into your own agents.