# Why an API key does not work for an autonomous agent > Autonomous agents are a poor fit for accounts, API keys and card subscriptions. The HTTP 402 status code plus a wallet lets an agent pay per call with no onboarding — here is why that model fits. Published 2026-06-28 · Updated 2026-08-15 · HTML version: https://invoket.com/blog/why-agents-pay-per-call-instead-of-api-keys --- The dominant way to sell an API — create an account, mint a key, attach a card, pick a monthly tier — was designed for a human developer who signs up once and integrates over weeks. An autonomous agent that discovers a useful endpoint mid-task fits none of those assumptions. The pay-per-call model built on the HTTP **402 Payment Required** status code removes the account, the key and the subscription: the agent pays for the single call it needs and moves on. This article explains why that model exists and why it suits agents, with sources for each claim. ## The account-and-key model assumes a human and a long relationship API keys solve a human problem: durable identity and billing for a developer who will integrate once and call for months. That model carries assumptions an autonomous agent breaks: - **Onboarding is manual.** Signing up, verifying an email, generating a key and entering card details is a human workflow. An agent that finds a new endpoint at runtime cannot pause to fill in a form. - **The relationship is long-lived.** Subscriptions and tiers amortise a fixed setup cost over many calls. An agent that needs *one* sanctions check or *one* climate value has no relationship to amortise. - **The credential is a liability.** A long-lived secret key, attached to a card, handed to an autonomous process is exactly the kind of standing credential security teams try to eliminate. None of this is a flaw in API keys — it is a mismatch between a model built for humans and a caller that is not one. ## Card rails make true micropayments uneconomical Even if an agent could complete the onboarding, the card rail underneath is the wrong instrument for small, frequent payments. Card processing combines a percentage of the transaction with a **fixed per-transaction fee** — commonly in the range of roughly **$0.10 to $0.30** on top of a percentage of about 1.5–3.5%, according to merchant-fee guides from [Bankrate](https://www.bankrate.com/credit-cards/business/merchants-guide-to-credit-card-processing-fees/) and [Capital One](https://www.capitalone.com/learn-grow/money-management/credit-card-processing-fees/). That fixed component is the problem. It is roughly constant regardless of the amount, so as the price of a call shrinks toward a few cents, the fee dominates or exceeds the payment itself. A sub-cent or few-cent API call simply cannot be settled economically on a card rail. Micropayments are not a pricing choice the card networks declined to offer; they are structurally uneconomical there. ## HTTP already reserved a status code for this The web's designers anticipated paid resources. **402 Payment Required** has been part of the HTTP status registry for decades, and the current HTTP semantics specification, [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html), still lists it as *reserved for future use* — deliberately leaving the door open without blessing any particular payment rail, wallet format or settlement model ([MDN summary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402)). That reservation is what a pay-per-call protocol fills in. The server answers an unpaid request with `402` and a description of how to pay; the client pays and replays the request. No account, no session, no stored key — the payment travels with the request. ## x402: a wallet, a 402, a replay [x402](https://github.com/coinbase/x402) is an open standard (Apache-2.0, co-stewarded through the x402 Foundation) that implements exactly this loop over HTTP. Per the Coinbase Developer Platform [overview](https://docs.cdp.coinbase.com/x402/welcome), the flow is: 1. The client requests a resource. 2. The server responds with **`402 Payment Required`** plus the payment requirements (amount, accepted rails) in a header. 3. The client signs a payment payload for one of the offered rails and **replays** the request with it attached. 4. The server verifies the payment — locally or through a facilitator — and, if valid, returns **`200 OK`** with the resource. The payment is a stablecoin transfer settled on-chain, so there is no account to create and no card on file. The agent needs only a funded wallet and the ability to follow a `402`. That is the entire onboarding. ## Why this fits autonomous agents Map the pay-per-call loop back to the agent's constraints and the fit is direct: - **No onboarding.** Discovery and payment happen in the same request cycle; the agent never leaves the loop to sign up. - **Per-call economics.** The agent pays for the one answer it needs, with no subscription to justify and no minimum to clear. - **No standing secret.** There is no long-lived key tied to a card to leak — the authority to pay is a per-request signature from a wallet the operator controls. - **Programmatic by construction.** A `402` is a normal HTTP response; handling it is code, not a billing portal. This is why Invoket exposes its endpoints with no account and no key: an agent discovers an endpoint, reads its price and rails, and settles the single call. The mechanics of that discovery — through the CDP x402 Bazaar or Invoket's own machine surfaces — are covered in [For agents](/docs/for-agents), the request/pay/replay cycle with runnable snippets in the [Quickstart](/docs/quickstart), and the accepted assets and networks in [Payments and rails](/docs/payments-and-rails). Actual prices and rails are never pinned in an article; they are served live by the [catalog](https://api.invoket.com/catalog). Pay-per-call is not a cheaper version of the API-key model — it is a different relationship. The key model rents access to a system over time; the 402 model buys one answer at a time. For a caller with no human to onboard and no relationship to amortise, buying one answer at a time is the model that fits. ## Sources - x402 protocol and flow — [coinbase/x402 (GitHub)](https://github.com/coinbase/x402), [Coinbase Developer Platform: x402 overview](https://docs.cdp.coinbase.com/x402/welcome). - HTTP 402 semantics — [RFC 9110, HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html), [MDN: 402 Payment Required](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/402). - Card processing fees — [Bankrate: merchant's guide to credit card processing fees](https://www.bankrate.com/credit-cards/business/merchants-guide-to-credit-card-processing-fees/), [Capital One: credit card processing fees](https://www.capitalone.com/learn-grow/money-management/credit-card-processing-fees/).