x402 Payment API: Pay-Per-Request Crypto APIs for AI Agents
How the x402 payment protocol enables AI agents to pay per API request in USDC on Base. Full guide to agent-native API monetization with the Peerlytics API as a working example.
HTTP status code 402 is "Payment Required." It was reserved in the HTTP/1.1 spec back in 1999 and then sat unused for 25 years. Nobody knew quite what to do with it, because the web didn't have a primitive for machine-to-machine payment. In 2025, Coinbase and the broader Base ecosystem finally put 402 to work: x402, an open payment protocol that uses USDC on Base to settle API calls directly, with no accounts, no keys, and no rotation. This guide walks through what x402 is, why it matters for AI agents, and how to use the Peerlytics API as a working example.
The problem x402 solves
Traditional API billing is built for humans. You sign up on a website, paste a credit card, get issued an API key, rotate the key every 90 days, and pay an invoice each month. The whole workflow assumes a human operator who can click through billing flows, maintain vaults for secrets, and respond to "your payment method is expired" emails.
AI agents don't have any of that. An autonomous agent running a research task has no email address, no human to paste a card, no vault to store keys, and no ability to respond to out-of-band signup prompts. If you want agents to consume APIs directly, you need a payment mechanism the agent itself can negotiate at the moment of the request.
How x402 works
The flow is deceptively simple:
- Agent makes an unfunded request. The agent calls
GET https://peerlytics.xyz/api/v1/orderbookwith no authentication. - Server responds with HTTP 402. The response body is a JSON payment requirement: "to fulfill this request, send $0.001 USDC on Base to address
0x..., referencing nonce0x.... Here's the paymaster URL you can use to settle it." The response includes a machine-readable schema so the agent knows exactly what to do. - Agent constructs a payment. The agent signs either a direct USDC transfer or an EIP-2612 permit authorizing the server to pull funds. The signed payload is encoded and attached as an
X-PAYMENTrequest header. - Agent retries the request with the payment. Same endpoint, now with the
X-PAYMENTheader set. - Server verifies and responds. The server either settles the payment on-chain immediately or delegates to a paymaster that guarantees settlement, then serves the API response.
Total overhead is a few hundred milliseconds of round-trip plus gas costs. For an agent doing thousands of calls per day, the amortized cost per request stays under a cent.
Why Base and USDC
x402 is chain-agnostic in principle, but the reference implementation uses USDC on Base. The reasoning is practical:
- Stable unit of account. USDC is pegged 1:1 to USD. API pricing in dollars doesn't fluctuate with ETH volatility.
- Cheap settlement. Base transactions cost a fraction of a cent. An x402 payment for a $0.001 API call makes sense on Base but would be absurd on Ethereum mainnet where gas alone would dwarf the API cost by 1000x.
- Fast finality. Base has 2-second block times, and Circle's CCTP lets USDC move in from most chains without bridge risk.
- Coinbase distribution. 100+ million verified Coinbase users have USDC-ready wallets and Base connectivity, which makes agent bootstrapping trivial.
Other implementations on other chains are possible and the protocol is open. But for the near-term, Base + USDC is the dominant stack.
Worked example: Peerlytics API with x402
The Peerlytics API accepts x402 on all paid endpoints. Here's a minimal example using the @peerlytics/sdk package, which handles the x402 dance internally.
import { PeerlyticsClient } from '@peerlytics/sdk';
import { privateKeyToAccount } from 'viem/accounts';
// Agent's USDC-funded wallet on Base
const account = privateKeyToAccount(process.env.AGENT_KEY);
const client = new PeerlyticsClient({
baseUrl: 'https://peerlytics.xyz/api/v1',
auth: { mode: 'x402', account },
});
// Each call signs and attaches a payment automatically
const orderbook = await client.getOrderbook({ platform: 'venmo' });
const summary = await client.getAnalyticsSummary({ period: 'mtd' });
const search = await client.explorerSearch({ q: '0xabc...' });Each call triggers the 402 dance: the SDK makes the unfunded request, receives the 402 response, constructs and signs the payment proof, and retries. The agent just sees method calls — the payment mechanics are invisible.
For non-SDK integrations (Python, Go, Rust), you handle the flow manually: make the request, catch the 402 response, parse the payment requirement, construct the signed payload, retry with the X-PAYMENT header. The x402 spec documents the exact payload formats.
x402 vs API keys
| Dimension | x402 | API key |
|---|---|---|
| Onboarding | None — agent just needs a wallet | Signup, verification, dashboard |
| Billing cadence | Per request (settled on-chain) | Pre-paid credits or monthly invoice |
| Key rotation | N/A (no keys) | Required, typically 90 days |
| Revocation | Automatic — no payment, no access | Manual via dashboard |
| Best for | Agents, ephemeral scripts, zero-trust workflows | Server-to-server integrations with predictable volume |
When NOT to use x402
x402 is the right tool for agent and ephemeral workloads, but there are cases where traditional API keys are still better:
- High sustained volume. If you're making millions of calls per day, the per-request payment overhead becomes meaningful. Pre-paid credits with a single invoice are more efficient.
- Fiat-only billing. Some organizations can't (or won't) hold USDC on Base. API keys billed via credit card or invoice work around this.
- Strict compliance requirements. If your compliance team requires a signed contract with the API provider, x402's anonymous-by-default flow isn't a fit. API keys with a business contract are the right choice.
Security considerations
x402 has a few sharp edges worth understanding:
- Replay attacks. Payment proofs include a nonce that the server tracks. A proof can only be redeemed once. If your client retries an aborted request, it needs to generate a new payment proof, not reuse the old one.
- Upfront settlement vs paymaster trust. Some x402 implementations settle immediately on-chain (slow, ~2-second block time on Base); others use a paymaster that guarantees settlement off-chain (fast, but requires trusting the paymaster for a short window). Check which mode the API you're using operates in.
- Wallet key management. The agent holds a private key that can move USDC. Standard hot wallet security rules apply: limit the balance the agent holds, keep the key in a secure environment, monitor the address for suspicious activity.
Peerlytics x402 details
Peerlytics implements x402 with the following configuration:
- Network: Base mainnet (chain ID 8453)
- Token: USDC (Circle's native USDC on Base)
- Per-request cost: $0.001 across all paid endpoints
- Settlement mode: EIP-2612 permit with 1-hour expiry; server settles via paymaster
- Nonce handling: server-issued, single-use
- Free endpoints:
/meta/platforms,/meta/currencies, and public data on network.peerlytics.xyz require no payment
Ecosystem and adoption
x402 is a young protocol but adoption is moving fast. Coinbase's Developer Platform (CDP) includes an x402 SDK, and several production APIs accept it as of early 2026. The protocol's biggest near-term catalyst is the rise of agentic AI — as more AI systems gain autonomy to consume external services, x402 is the natural primitive for monetization that doesn't require humans in the loop.
We've also started seeing composite agent stacks where one agent pays another agent via x402 for specialized services (market analysis, translation, code generation). This is the "machine economy" narrative that people talked about for years and never had the primitives to build.
Where to go next
- ZKP2P API guide — full endpoint catalog for Peerlytics
- Developer docs — API keys, pricing, x402 setup
- x402 protocol spec — formal definition and payload formats
- @peerlytics/sdk — TypeScript SDK with built-in x402 support
Frequently asked questions
What is x402?
An open payment protocol that uses HTTP 402 to negotiate per-request payments in USDC on Base. Servers respond to unfunded requests with a 402 payment requirement; clients retry with a signed payment proof attached. No accounts, no keys.
Why does x402 matter for AI agents?
Traditional API billing assumes a human operator. Agents don't have one. x402 lets an agent pay per request directly from a USDC balance, making it the first payment primitive that fits autonomous AI workflows.
How does x402 work under the hood?
Server responds 402 with a payment requirement. Client signs a USDC transfer or permit, attaches it as X-PAYMENT header, retries. Server verifies and serves the response.
Is x402 production-ready?
Yes. Peerlytics accepts x402 on all paid endpoints as of 2026. The reference implementation is in the Coinbase Developer Platform SDK and @peerlytics/sdk.
What does each x402 request cost?
Set by the provider. Peerlytics charges $0.001 per request. Base gas costs are a fraction of a cent.