x402: Pay-Per-Call API Access for Agents
How the HTTP 402 status code lets an autonomous agent pay for an API request inline, removing the need to provision and manage a long-lived API key.

402 Payment Required has been in the HTTP specification since 1997, reserved
and unused. x402 finally gives it a job, and the job turns
out to matter a lot for autonomous agents.
The problem with API keys
The standard model assumes a known party integrating ahead of time: sign up, get a key, prepay a balance, store the secret, rotate it periodically.
That model fits a company building a product. It fits an autonomous agent badly:
| Assumption | Why it breaks for agents |
|---|---|
| The caller is known in advance | The agent may be spawned on demand |
| A long-lived secret is safe to store | Agents run in ephemeral, shared contexts |
| One key, one spend limit | A shared key means one agent can drain the balance |
| Someone rotates the key | Nobody is watching an autonomous loop |
The spend problem is the sharp one. Hand an agent a provisioned key and you have handed it your entire credit balance, bounded only by how well you scoped the task.
How x402 works
- The client requests a resource.
- The server responds 402 with payment terms.
- The client pays.
- The request proceeds.
Payment happens in the request cycle. There is no account, no prepaid balance, and no secret that outlives the call.
What changes
| Provisioned key | x402 |
|---|---|
| Set up in advance | No setup |
| Shared spend limit | Bounded per request |
| Long-lived secret to store and rotate | Nothing persistent to leak |
| Revoke by rotating the key | Nothing to revoke |
| You pay for the agent's mistakes | Spend is capped per call |
For an agent that runs occasionally — or one you do not control, or one a customer runs against your data — there is no credential to provision, leak or clean up.
When to use which
x402 is not a replacement for keys. It is the right tool in a narrow, growing set of cases:
Use x402 when the caller is autonomous, short-lived, untrusted, or unknown in advance; or when you want a hard per-call spend ceiling rather than a shared pool.
Use a key when you are a known team building a product with predictable volume. It is simpler, and prepaid credits are cheaper per call at scale.
Where it sits in the agent stack
x402 is the payment rail, not the interface. An agent still reaches the data through one of:
| Interface | Guide |
|---|---|
| MCP server | Crypto Portfolio MCP Server |
| Rust CLI | A Rust CLI for Portfolio Data |
| REST API | Endpoint reference |
The broader picture — and the failure modes specific to agents consuming portfolio data — is in AI Agent Tools for Crypto Portfolio Data.
The direction of travel
The interesting shift is agents that act rather than summarise: rebalancing, monitoring liquidation risk, reconciling transactions. Each of those implies an agent making purchasing decisions about the data it needs, at a frequency no human is approving individually.
Machine-to-machine payment for API calls is infrastructure for that, and it is worth building against before it is urgent — the same argument as machine-readable content for LLMs.
Keep reading
AI AgentsAI Agent Tools for Crypto Portfolio Data
A survey of how AI agents get on-chain data — MCP servers, agent skills, CLIs and pay-per-call rails — and the failure modes specific to autonomous consumption.
2 min read
AI AgentsA Crypto Portfolio MCP Server for AI Agents
How to give Claude, Codex or Gemini live on-chain portfolio data through an MCP server, and why token-only APIs make agents confidently wrong about wallets.
2 min read
AI AgentsA Rust CLI for Crypto Portfolio Data
Query multi-chain portfolios, transactions and NAV from the terminal with a single Rust binary — built for shell pipelines, CI jobs and sandboxed AI agents.
2 min read