x402 vs API Keys: Choosing a Payment Model for Machine-to-Machine APIs
API keys are how most APIs work: provision a credential, attach it to every request, bill the account holder monthly. For developers building steady-state integrations with a clear billing relationship, this is fine. For autonomous agents, ephemeral scripts, and systems that need to transact without establishing an account first, keys create structural friction that doesn't have a clean solution inside the key-based model.
The HTTP 402 payment protocol — x402 — is the standards-based alternative. Payment is per-request, in USDC, at the moment of the call. Any caller with a funded Solana wallet can pay — no provisioning, no credential, no account required. DocketLayer is built on this model exclusively.
The Problem with API Keys
API keys bundle authentication, authorization, and billing into a single credential. Keys must be provisioned before any request can be made — which requires a human-facing signup flow. Keys must be rotated when they leak. Keys attach to accounts, which means usage aggregates across all callers sharing a key, making individual-query attribution difficult without custom metering on top. And the API provider has to run account management, billing integration, and user state to support the model.
For AI agents, the problem is more specific: an agent cannot provision its own API key. It inherits one from its operator. That ties the agent's capabilities to the operator's account and creates cost-attribution complexity across agents. The agent can never transact on its own behalf without the operator's infrastructure in the loop.
How x402 Works
x402 uses the HTTP 402 status code as a machine-readable price signal. When a client requests a resource without payment, the server responds with a 402 and a payload describing the required payment: amount, currency, recipient address, and an expiry. The client builds a USDC transaction on Solana, signs it with its wallet, and retries the request with an x402-payment header containing the encoded transaction. The server verifies the transaction and returns the resource.
No account required. No credential provisioned. Any wallet with sufficient USDC balance can pay. The payment and the resource exchange happen in a single request-response cycle — no out-of-band billing system, no webhook for payment confirmation. For a full implementation walkthrough, see the How x402 Works guide.
Side-by-Side Comparison
Setup: API keys require account creation, email verification, and credential storage. x402 requires a funded Solana wallet — any standard SPL wallet works, generated programmatically in seconds.
Per-request cost attribution: With API keys, costs aggregate at the account level unless the provider builds usage-level metering. With x402, every request has an on-chain transaction record tying cost to a specific wallet, timestamp, and query.
Credential exposure: API keys are transmitted with every request and can leak. A wallet's signing key is never transmitted — only the signed transaction. If a wallet is compromised, the caller generates a new one. There is nothing to rotate.
Overage handling: API key plans have rate limits and overage charges resolved post-hoc. x402 payments are prepaid at request time — there is no account to go into arrears.
Provider infrastructure: API keys require the provider to run account management, billing integration, and invoicing. x402 payment verification is a stateless on-chain check with no provider-side user state.
AI Agents and Autonomous Payment
x402 was designed with autonomous callers in mind. An AI agent can hold a Solana wallet directly — the keypair is bytes the agent stores and uses. When the agent encounters a 402 response, it parses the payment requirement, builds the transaction, and retries — without human involvement. The agent's budget is defined by its wallet balance, and every payment is observable on-chain.
This makes x402 a natural fit for agent-to-agent transactions and for operators who want agents to have controlled, auditable spending authority without sharing a global API key that grants unlimited access to everything the key covers.
When API Keys Still Make Sense
Keys are appropriate when: callers are human developers building steady-state integrations rather than making on-demand requests; the use case involves high-volume queries where a subscription rate is more economical than per-request pricing; the operator wants centralized billing rather than per-agent wallet management; or the deployment environment doesn't support wallet key storage.
These are valid reasons to choose a key-based API over x402. DocketLayer is x402 only — if your use case requires centralized subscription billing or API key management, that shapes which data provider fits your architecture.