How an AI agent pays for an API with x402 (HTTP 402, USDC, no API key)

Posted on Oct 25 • Originally published at fastaf.co

Most APIs assume a human is somewhere in the loop: someone signs up, verifies an email, adds a card, copies an API key into an environment variable and keeps an eye on the monthly invoice. That works for applications. It works less well for autonomous AI agents, which may need a single piece of data from a service they have never used before, at 3 a.m., with nobody around to fill in a signup form.

x402 is an attempt to fix that by using a status code that has been sitting in the HTTP spec for decades: 402 Payment Required. This article explains how the flow works, shows a real 402 response from a live API ( api.fastaf.co ), walks through a minimal TypeScript client, and discusses when per-call payment makes sense and when it does not.

HTTP 402 was reserved early on "for future use" and, for most of the web's history, nobody used it in a standard way. x402 gives it a concrete meaning: the server answers an unpaid request with 402 and a machine-readable description of what it wants to be paid, in which token, on which network and to which address. The client signs a payment authorization and retries the same request. If the server accepts it, the client gets a normal 200 response plus a settlement receipt.

There is no account, no API key and no session. The payment is the authentication. For an agent, that means the only prerequisite is a wallet holding the right token.

Libraries such as @x402/fetch and @x402/axios handle steps 2 and 3 transparently, so application code looks almost like a plain fetch.

FastAF, a web scraping and SERP API, exposes all 16 of its endpoints over x402 v2 at GET https://api.fastaf.co/x402/v1/{endpoint}, with the same query parameters as its keyed API. Here is what an unpaid Google search request returns (captured on 2026-10-25):

GET https://api.fastaf.co/x402/v1/serp?query=best%20espresso%20machine → HTTP / 2 402 Enter fullscreen mode Exit fullscreen mode The JSON body (excerpt):

{ "error": { "code": "payment_required", "message": "Payment is required for this request." }, "price": { "usd": "0.005000", "credits": 5, "asset": "USDC", "network": "eip155:8453" }, "how_to_pay": "Sign the PAYMENT-REQUIRED challenge with an x402 v2 client (for example @x402/fetch) and retry with PAYMENT-SIGNATURE. Settled only if the request succeeds.", "docs": "https://fastaf.co/docs/#x402", "x402Version": 2 } Enter fullscreen mode Exit fullscreen mode The body is there for humans and for debugging. The part an x402 client actually uses is the PAYMENT-REQUIRED header, which decodes to (excerpt):

{ "x402Version": 2, "resource": { "url": "https://api.fastaf.co/x402/v1/serp?query=best%20espresso%20machine" }, "accepts": [ { "scheme": "exact", "network": "eip155:8453", "amount": "5000", "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", "payTo": "0x05B75e13f071A09A26B50a18Ce5BD02a0755d76F", "maxTimeoutSeconds": 300, "extra": { "name": "USD Coin", "version": "2" } } ] } Enter fullscreen mode Exit fullscreen mode A few details worth noticing:

A minimal TypeScript client, based on the official @x402/fetch README from the coinbase/x402 repository:

// npm i @x402/fetch @x402/evm viem import { wrapFetchWithPaymentFromConfig } from " @x402/fetch "; import { ExactEvmScheme } from " @x402/evm "; import { privateKeyToAccount } from " viem/accounts "; const account = privateKeyToAccount ( process. env. AGENT_WALLET_KEY as `0x ${ string } ` ); // wallet holding USDC on Base const pay = wrapFetchWithPaymentFromConfig ( fetch, { schemes: [{ network: " eip155:8453 ", client: new ExactEvmScheme ( account ) }], }); const res = await pay ( " https://api.fastaf.co/x402/v1/serp?query=best%20espresso%20machine " ); console. log ( res. status, res. headers. get ( " X-FastAF-Credits-Used " )); console. log ( await res. json ()); Enter fullscreen mode Exit fullscreen mode The wrapped pay function behaves like fetch: on a 402 it reads the challenge, signs with the agent's wallet and retries. The 200 response carries the search results, an X-FastAF-Credits-Used header and the PAYMENT-RESPONSE settlement receipt.

Two practical notes. First, the wallet key is a real secret: give the agent a dedicated wallet funded with a small amount of USDC, not your main one. The balance of that wallet then acts as a natural spending limit. Second, always pay the amount in the live challenge rather than a hard-coded price, because options can change the cost of a call.

On FastAF the x402 price is the endpoint's credit cost at $0.001 USDC per credit. Live 402 quotes for default parameters on 2026-10-25:

Options can raise the price: for example serp with advance_search=true costs 10 credits. The quote in the challenge is authoritative.

An important property for agents: payment is settled only if the request succeeds. A blocked page, an empty answer or a target that returns 404 produces an error response and no settlement, so an agent retrying against a difficult site does not pay for failures.

Many agents reach tools through the Model Context Protocol rather than raw HTTP. FastAF runs a hosted MCP server at https://api.fastaf.co/mcp with 16 tools, but its tool calls need an API key or OAuth; the MCP server does not accept x402 payments itself. In practice that splits usage into two paths: MCP with a key and prepaid credits, or direct HTTP with x402 and no account. Nothing stops an agent from using x402 over HTTP as an ordinary tool alongside its MCP tools.

x402 turns payment into a property of the HTTP request itself: one unpaid call to discover the price, one signed retry to get the data. For agents, that removes the signup step entirely and replaces an API key with a wallet whose balance doubles as a budget. The flow is simple enough to read in a single 402 response, and client libraries reduce it to a wrapped fetch.

Per-endpoint prices, the full 402 example and a comparison with prepaid credits are on the x402 Scraping API page. Protocol details are in the FastAF docs and the coinbase/x402 repository.