An API key answers one question: who is calling? It doesn't answer how much they've used, whether they can afford the next call, or what happens when they run out of budget — that's all bolted on separately, usually with a billing dashboard, a usage meter, and a human checking both every so often. x402 answers a different question: has this specific call been paid for? That's a narrower question, and for an autonomous caller, a much more useful one.
Issuing an API key assumes a sequence: someone signs up, verifies an email, maybe attaches a card, generates a key, and stores it somewhere a program can read it later. Every one of those steps assumes a human is present at least once to do the signing up. It also assumes the key, once issued, is good until revoked — which means a leaked key stays valid until someone notices, and a budget overrun stays invisible until a bill shows up at the end of the month.
None of that is wrong for a human developer integrating an SDK. It's a mismatch for a caller that is itself a piece of software deciding, call by call, whether a given API is worth hitting.
x402 doesn't issue anything up front. Every call carries its own payment, signed at the moment of the call, for exactly the amount that call costs. There's no key to leak, because there's no standing credential — a signed payment under the exact scheme is only valid for the specific request it was created for. There's no usage meter to reconcile at the end of the month, because the cost and the call happen in the same HTTP exchange. And there's no step where a human has to be present, because signing a payment is something a wallet can do programmatically — see what x402 actually is for the full request/response shape.
This is also why a failed call costs nothing under x402 in a way that's structurally true, not just a billing policy: DimeBox only settles a payment if its own response comes back under 400. An API-key-metered service can promise not to bill failed calls, but that's a line in a billing engine someone has to get right. Under x402, payment and successful execution happen in the same request — see why DimeBox never charges for a failed call.
Revoking an API key means finding it in a dashboard and clicking delete, hoping whatever process was using it notices the next call fails and stops retrying. There's nothing equivalent to revoke under x402, because there's nothing standing to revoke — a wallet that's compromised is a wallet problem (move the funds, stop signing with that key) rather than an API-provider problem. That's a real tradeoff, not a pure win: it means an API provider has no lever to cut off a specific caller mid-stream the way revoking a key does. What it loses in that lever, it gains in having no leaked long-lived secret sitting in a config file in the first place.
The gap between the two models gets more visible, not less, as the number of callers grows. A team running one agent with one API key can get away with checking a dashboard occasionally. A team running a fleet of agents, each hitting several different paid APIs on its own schedule, can't realistically keep that many keys, budgets, and revocation states straight by hand — every added agent is another credential to provision, store, and eventually rotate. Under x402, adding another agent to the fleet means giving it a wallet, not registering it with every API it might ever call. See budgeting for a fleet of autonomous agents that pay their own way for what that looks like once you're managing more than a handful.
API keys aren't obsolete — they're the right tool when the caller is a known, long-running system that will make thousands of calls under one identity and benefits from a single bill at the end of the month. x402 is the right tool when the caller is one agent among many, calling intermittently, with no existing account relationship to the API it's hitting, and a wallet instead of a card on file. DimeBox supports both shapes, in fact: pay per call with a signed x402 payment, or fund a wallet with a card and authenticate with Authorization: Bearer <wallet_secret> instead, which skips the 402 round trip entirely while charging the same per-call prices. Neither path requires a signup form or an account team.
This post is specifically about the "who's the caller" problem. For a side-by-side across x402, API keys, and wallet secrets covering more dimensions — revocability, rate limiting, how each fails when something goes wrong — see API keys vs wallet secrets vs x402 signatures. For how this compares to the other major machine-identity model on the web, OAuth, see x402 vs OAuth. And for the broader design implication — building an API around the assumption that the caller is a program, not a person filling out a form — see designing APIs that assume the caller is a machine.