API Key

An API key is a secret string a developer obtains — usually after creating an account — and attaches to each request, typically in a header like Authorization or X-API-Key. It proves the caller is authorized and lets the provider attribute usage to an account for billing, rate limiting, and abuse control.

Keys are deliberately simple: no cryptographic handshake, no token refresh, just a shared secret. That simplicity made them the default authentication scheme for two decades of web APIs.

A key bundles three functions that are conceptually separate. Identity: which account is calling. Authorization: what that account is allowed to do, often by plan tier. Metering: how much it has used, feeding invoices and quota enforcement.

The bundling is the source of most key pain. Rotating a leaked key breaks metering continuity; sharing a key across services blurs identity; and upgrading a plan means the same key suddenly means something different. Larger systems usually graduate to OAuth or signed requests precisely to unbundle these concerns.

The key model assumes a human signs up before the first request: read the docs, create an account, verify an email, paste a secret into config. An autonomous agent that discovers a useful API mid-task cannot do any of that. Pre-provisioning is no better — an agent might plausibly touch hundreds of services, and nobody is going to maintain hundreds of accounts, keys, and subscriptions on the chance the agent needs one.

Keys are also standing credentials: they leak in logs and repos, and a stolen key works until someone notices. For fleets of agents, the secret-distribution problem alone becomes a genuine operational burden.

x402 reframes the problem. Instead of proving who you are, the caller proves it has paid. A server answers an unkeyed request with HTTP 402 and a price; the agent's wallet signs a per-call USDC payment (from $0.01), the request retries with the payment attached, and settlement lands on Base in about two seconds — before the handler runs. No account, no signup, no secret to leak; the payment itself is the credential, and an Ed25519 signed receipt documents each call.

This is why agentic commerce is often framed as an alternative to API keys: the agent pays as it goes rather than enrolling in advance.

In practice many providers run both. Keys still make sense for high-volume contracted customers who want invoicing, custom terms, and support relationships. x402 covers the long tail: anonymous agents, one-off calls, and users who will never justify an enterprise agreement. A server listed on the Loomal Index can keep its existing key-based plans while exposing a per-call x402 price for callers who arrive with a wallet instead of an account.

The likely steady state is segmentation by caller type: humans and contracted integrations on keys, autonomous agents on per-call payment — with the same endpoints serving both.