# 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.

- **URL:** https://octav.fi/blog/x402-pay-per-call-api
- **Published:** 2026-04-04
- **Author:** Octav Team — Portfolio Intelligence for Digital Assets
- **Topic:** AI Agents
- **Tags:** x402, ai-agents, payments
- **Source:** Octav, Practical guides on crypto NAV reporting, multi-chain portfolio management and digital asset APIs, from the team behind Octav.

---
`402 Payment Required` has been in the HTTP specification since 1997, reserved
and unused. [x402](https://x402.org) 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

1. The client requests a resource.
2. The server responds **402** with payment terms.
3. The client pays.
4. 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](/crypto-portfolio-mcp-server) |
| Rust CLI | [A Rust CLI for Portfolio Data](/octav-cli-rust) |
| REST API | [Endpoint reference](/crypto-portfolio-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](/ai-agent-tools-crypto-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](/ai-agent-tools-crypto-data).