What Is an x402 API? Pay-Per-Call APIs for AI Agents, Explained

By Aria Pramesi, founder of InboxPolicy · Updated July 10, 2026

x402 is a protocol, not a product: any API can adopt it. This page defines the term, walks the payment flow with a real 402 response from a live x402 API, and covers the ecosystem building around it as of July 2026.

Where the name comes from

HTTP has reserved status code 402 for "Payment Required" since the original HTTP/1.1 specification, but for three decades almost nothing implemented it. x402 is an open protocol, originally developed by Coinbase and published in May 2025, that finally gives that status code a defined meaning: when a client requests a resource without payment, the server responds 402 with structured payment requirements instead of a generic error, the client signs and attaches a payment, and retries. The project has since moved to community governance under the x402 Foundation, with Coinbase's original repository continuing as a development fork. Version 2 of the protocol (x402Version: 2 in every response) is current as of July 2026; a published migration guide covers the v1-to-v2 change.

The payment flow, step by step

1. Client requests the resource, unauthenticated. No API key, no signup, no session.
2. Server responds 402 Payment Required with a JSON body describing the resource and one or more accepted payment options: chain, token, amount, and recipient address.
3. Client signs a payment authorization for the exact quoted amount. On EVM chains, the exact scheme signs this as an EIP-3009 transferWithAuthorization, a gasless, off-chain-signed USDC transfer, so the caller doesn't need native gas tokens or a separate approval transaction.
4. Client retries the same request with the signed payment attached to a payment header.
5. Server (or a facilitator acting for it) verifies and settles the payment on-chain, then returns the actual response along with a settlement receipt.

A real 402 response

This is the live, unmodified response from InboxPolicy's own verification endpoint, fetched with no payment attached, no API key:

$ curl -i https://api.inboxpolicy.com/v1/decide \
  -H "content-type: application/json" \
  -d '{"email":"[email protected]"}'

HTTP/2 402
content-type: application/json; charset=utf-8

{
  "x402Version": 2,
  "error": "PAYMENT-SIGNATURE header is required. Pay per call, or buy a credit pack at https://inboxpolicy.com/#pricing for lower per-check pricing.",
  "resource": {
    "url": "https://api.inboxpolicy.com/v1/decide",
    "description": "InboxPolicy https://api.inboxpolicy.com/v1/decide — send-decision email verification, pay per call",
    "mimeType": "application/json",
    "serviceName": "InboxPolicy",
    "tags": ["email-verification", "send-decision"]
  },
  "accepts": [
    {
      "scheme": "exact",
      "network": "eip155:8453",
      "amount": "10000",
      "payTo": "0x265018afAbC7a7b51E2B742834Aabf35F48165d9",
      "maxTimeoutSeconds": 60,
      "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
      "extra": {"name": "USD Coin", "version": "2"}
    }
  ]
}

Reading the pieces: network is a CAIP-2 chain identifier, eip155:8453 is Base mainnet. amount is 10000 in USDC's smallest unit (6 decimals), which is $0.01. asset is the USDC token contract address on Base, and payTo is the wallet that receives payment. A generic x402 client library reads this accepts array, signs a matching payment, and resubmits with a PAYMENT-SIGNATURE header carrying the signed authorization. InboxPolicy verifies and settles it, then returns the send decision plus an on-chain receipt in that same retried call, no separate billing step.

Why agents specifically need this

x402's own motivation is machine-to-machine payments: an AI agent evaluating hundreds of API calls a day can't fill out a signup form, verify an email, enter a credit card, or manage a growing pile of API keys for every tool it might need once. A keyless, pay-per-call model removes all of that. The agent doesn't need a human in the loop to provision access; it needs a funded wallet and a client library that knows how to read a 402 and sign a response. That's the core appeal: billing collapses into the same HTTP request that does the work, and there's no account state for either side to manage.

This doesn't require the caller to be an AI agent. Any HTTP client, including a person with a browser wallet extension, can complete an x402 flow. But the friction it removes, no signup, no KYC, no stored card, matters most to a caller that can't fill out a form at all, which is why agent tooling has driven almost all of the protocol's adoption.

The x402 ecosystem, as of July 2026

The following is an attributed snapshot of how the ecosystem is organized, not part of the protocol specification itself:

• Directories. Sites such as x402scan and various "awesome-x402" lists on GitHub catalog live x402 endpoints so agents and developers can discover pay-per-call APIs without prior knowledge of who runs them.
• MCP servers. Several projects expose x402 payment and discovery as Model Context Protocol tools, so an LLM agent can call a paid API through the same tool-calling interface it already uses, without hand-rolling the 402-then-retry logic itself.
• Facilitators vs. self-hosted settlement. A server can verify and broadcast x402 payments itself, or delegate that to a third-party facilitator service that handles on-chain verification and settlement on its behalf. Facilitators trade a small amount of trust for not needing to run node infrastructure or hold settlement keys directly; self-hosting avoids that dependency at the cost of running the infrastructure yourself.

These categories are moving quickly and vendor-specific claims in this space should be verified against each project's own documentation before you rely on them.

x402 in practice

On InboxPolicy, one x402 call is exactly one price: $0.01 per email verification, quoted and settled in USDC on Base, no account required. You need an EVM-compatible wallet holding a small amount of USDC on Base and an x402-aware HTTP client to sign the payment; from there, every call is a self-contained request-pay-response cycle. A working example client is available at github.com/sorcerai/inboxpolicy-examples. Batches keep the same model: a keyless batch of up to 5,000 emails gets one combined quote instead of one payment per address.

InboxPolicy's own x402 verification flow, including the batch path and what stays free (cache hits, malformed-email rejection, idempotent retries), is covered in more detail on the x402 email verification guide.

Frequently asked questions

Related guides

• x402 Email Verification: Pay-Per-Call, No Account
• API documentation
• The Send Decision Framework
• Email Verification for AI Agents
• MCP Email Verification for Agents