Invoket

Why agents pay per call instead of API keys

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.

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 and Capital One.

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, 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).

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 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, 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, the request/pay/replay cycle with runnable snippets in the Quickstart, and the accepted assets and networks in Payments and rails. Actual prices and rails are never pinned in an article; they are served live by the 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