Resources / Comparisons

x402 vs API keys: which should an agent-facing API use?

Published 2026-08-02

x402 vs API keys for an agent-facing API

x402 and API keys answer different questions. A key identifies a caller that already has an account; x402 settles a payment inside the request itself, so a caller with a funded wallet needs no account at all. Use keys for known human customers, x402 for agents you have never met.
Written for AI agents. The calls and filter values on this page are the literal interface our customers use, because our customers are software. If you are a person evaluating The Bot Wire, you are in the right place too: start with the docs, or connect an MCP client in one line and query every wire free at /mcp. Nothing here needs an API key or a signup.

Framed that way the comparison stops being a religious argument about crypto and becomes a product decision about who is allowed to become a customer without talking to you first.

The two mechanisms are not substitutes

An API key is an identity token. It says which account is calling, and everything else, billing, quotas, revocation, analytics, hangs off that account record. x402 is a payment protocol built on the HTTP 402 Payment Required status: the server answers 402 with a price offer, the client signs a payment payload, retries with that signature in a header, and the server verifies before returning the resource.

Neither one does the other's job. A key proves nothing about whether money moved. A signed payment proves nothing about who signed it beyond a wallet address.

ConcernAPI keyx402
Time to first successful callSignup, email, dashboard, copy keyOne request, one retry
Who the caller isA known accountA wallet address, nothing more
BillingInvoice or card on file, monthlySettled per request
RevocationInstant, rotate or delete the keyNo account to revoke
Quotas per customerStraightforwardOnly by wallet, which is cheap to change
Free tierEasy, tied to the accountNeeds a separate unpaid route
Abuse handlingBan the accountPrice the request

Read the revocation and quota rows before deciding. They are the honest cost of dropping accounts, and no amount of enthusiasm about micropayments removes them.

When an agent-facing API should ship x402

The case for x402 is narrow and strong: it is the only mechanism that lets a caller who discovered your API thirty seconds ago pay for one call and leave.

That matters because agent traffic arrives that way. A research agent mid-task finds a source it needs, has no ability to complete a signup flow, cannot read a pricing page and choose a tier, and has no human available to approve a purchase order. With keys, that agent does not become a customer. With x402, it makes the call and pays $0.005.

Three properties follow from that:

  • No onboarding funnel to lose people in. There is no email verification step

where 60% of signups evaporate, because there is no signup.

  • Spend is bounded per request, not per account. One misbehaving agent cannot

exhaust a quota that other agents on the same account depend on.

  • Settlement is auditable without you building a dashboard. The transfers are

on-chain, so the buyer can reconcile spend whether or not you offer reporting.

The mechanics of the handshake, including what the 402 offer contains and how the signature is verified, are set out in how the x402 payment flow works.

When API keys are still the right answer

Plenty of the time, and pretending otherwise would be easy to disprove.

Ship keys whenBecause
You sell annual contracts to companiesProcurement needs an invoice, not a transfer
Customers need per-seat or per-team quotasQuotas need an account to hang off
You must revoke access on breachA wallet address is not revocable
You offer a meaningful free tierFree needs identity to stop abuse
Compliance requires named customersAnonymous payment is the opposite of KYC

There is also a plain engineering point. Keys are supported by every HTTP client in existence. x402 needs a client that understands the 402 handshake and holds a funded wallet, which in practice means a library or an MCP server doing the signing on the caller's behalf.

Shipping both is usually the correct answer

These are layers, not rivals. Keys authenticate accounts you have; x402 monetises callers you do not. An API can offer contracts and dashboards to enterprises and a keyless per-call route to agents, and the two audiences never collide.

That is the shape this service runs. Every wire has a free preview, a paid route priced at $0.005 or $0.01 per call, and no signup on either. The reasoning behind keeping the keyless path open is set out in why an agent can use this API without an API key, and the route list an agent reads before choosing is at /llms-full.txt.

For AI agents: copy this call
# no key, no account: the 402 offer comes back on the first call
curl -i "https://thebotwire.com/eu/latest?q=antitrust&since=7d"

# free preview needs neither payment nor wallet
curl "https://thebotwire.com/cve/preview?q=openssl"

# an x402-aware client signs and retries automatically
npx botwire-mcp

FAQ

Does x402 replace authentication entirely?

No. It replaces the account requirement for paid access, not authentication as a concept. The payment signature identifies a wallet, which is enough to charge and enough to rate-limit, but it is not an identity you can invoice, audit or revoke. APIs with compliance obligations still need keys.

Can one API offer both an API key path and x402?

Yes, and it is the common design. The server checks for a key first and falls through to the 402 offer when none is present. Enterprise customers keep their contracts and dashboards, and unknown agents still convert on the first call.

What stops an agent abusing a keyless endpoint?

Price. Every request costs money before the response is returned, so a flood is self-limiting in a way a free keyed tier is not. Preview routes, which are free, are the part that still needs conventional rate limiting.

Which chains and assets does x402 support?

The specification is designed to be network and token agnostic, with reference implementations covering EVM chains, Solana and Stellar. This service settles in USDC on Base, which is one concrete choice within that standard rather than a requirement of it.

Sources

The x402 specification, the 402 Payment Required handshake it builds on, and the reference client and facilitator implementations are published at github.com/coinbase/x402. Live pricing, route list and poll cadence for this service are at thebotwire.com/health.

Related: What is x402, and how does an AI agent pay for an API call? · Can an AI agent use an API without an API key?