Fabler Labs → Guides → x402 vs. API keys

x402 vs. API keys: which one should your agent pay with?

Free · no signup · a fair comparison, not a hit piece · July 2026

If you're building an agent that needs to pay for a tool call — a search, a data lookup, a scan, a generated asset — you have two real options today: get an API key and a metered-billing account from the provider, the way software has bought API access for twenty years, or call an x402 endpoint and pay per request in USDC with no account at all. This page is a straight, technical comparison of the two, written by the team that runs one of each: a Stripe-metered human storefront and a live x402 machine store, x402.fablerlabs.com, selling the same underlying products and a few agent-priced API calls. We'll show you the real 402 handshake against our own store, and we'll tell you honestly where x402 isn't ready yet.

The two models, in one sentence each

API keys / metered billing is the pattern behind almost every paid API today (OpenAI, Anthropic, Twilio, most SaaS): a human creates an account up front — email, card on file, sometimes a KYC or business-verification step — gets issued a secret key, calls the API with that key attached, and gets billed in arrears, usually monthly, for aggregate usage.

x402 revives HTTP's long-dormant 402 Payment Required status code as a real, machine-to-machine payment handshake, standardized by the x402 Foundation (originally built at Coinbase). No account, no key, no signup: the caller pays for the specific call it's making, at the moment it's making it, and the payment itself is the authorization.

How an x402 request actually works

Three steps, all inside one logical exchange:

1. Ask. The client calls a paid endpoint with no payment attached — a completely normal HTTP request.
2. 402 challenge. The server replies 402 Payment Required with a JSON body under an accepts array: the pricing scheme (almost always "exact" — pay a fixed amount), the network, the amount in atomic units, the destination wallet (payTo), and a timeout.
3. Pay and retry. An x402-aware client (e.g. the x402-fetch library) signs a payment authorization for that exact amount, attaches it as an X-PAYMENT header, and retries the same request. A facilitator verifies and settles the payment on-chain; the server returns the real response with an X-PAYMENT-RESPONSE header confirming settlement.

The dominant settlement asset across live x402 deployments is USDC on Base, though the spec itself is chain- and asset-agnostic. Our own store settles USDC on Base through facilitator.xpay.sh, a facilitator that needs no API key on either side of the trade.

The honest comparison

The clean way to say it: API keys answer "who is this caller, and what do they owe me at the end of the month?" x402 answers "can this specific request pay for itself, right now, with no prior relationship?" Most businesses selling to humans should keep metered billing. A business selling narrow, cheap, well-defined calls specifically to autonomous software gains something metered billing structurally can't offer: a stranger agent can pay on the first request.

When NOT to use x402

This is the part a vendor pitching you x402 has an incentive to skip, so we won't:

• Your buyers are mostly humans. A person doesn't have a funded crypto wallet sitting in their browser the way an agent can have one wired into its tool loop. If your checkout is a person on a laptop, Stripe (or any card processor) is simply the better tool — familiar, reversible, no wallet required.
• You need chargeback/refund protection as a safety net. x402 payments are final. If your business model depends on being able to reverse a bad charge after the fact, you're taking on risk a card network would otherwise absorb for you.
• Your buyer-side tooling isn't there yet. The caller needs an x402-aware HTTP client (or MCP integration) and a wallet pre-funded with USDC on the right network. Plenty of agent stacks don't have that wired up yet — an endpoint no agent's client can pay is an endpoint nobody pays.
• You're not ready to hold and move crypto. Self-custody means you're responsible for a private key, and USDC — while a dollar-pegged stablecoin, not a volatile asset like ETH or BTC — has still de-pegged briefly under stress before (most notably during the March 2023 banking-sector event). Converting on-chain balances to fiat is an operational step you now own, that a card processor used to own for you.
• The ecosystem is genuinely early. Don't read a working demo as proven demand. We say the same thing about our own store below.

Worked example: a real 402 challenge against our own store

Everything above is easier to trust with a live example than a diagram. Here's what an unpaid call to our own x402.fablerlabs.com store actually returns — the real response shape from the standard x402-hono middleware, also documented in full on the machine-store page and in the build log that shipped it:

$ curl -s -X POST https://x402.fablerlabs.com/scan/secrets \
    -H "Content-Type: application/json" \
    -d '{"text":"..."}'

HTTP/1.1 402 Payment Required
Content-Type: application/json

{
  "x402Version": 1,
  "error": "X-PAYMENT header is required",
  "accepts": [
    {
      "scheme": "exact",
      "network": "base",
      "maxAmountRequired": "5000",
      "resource": "https://x402.fablerlabs.com/scan/secrets",
      "description": "Scan a text blob for accidentally-committed secrets.",
      "mimeType": "application/json",
      "payTo": "0x...",
      "maxTimeoutSeconds": 300,
      "asset": "0x..."
    }
  ]
}

# maxAmountRequired is USDC's atomic unit (6 decimals): 5000 = $0.005.
# No account was created, no card was charged, no human looked at this
# exchange while it happened.

Now compare that to the code an agent would write against each model. The x402 side pays our own live endpoint with no prior signup, using the standard x402-fetch client library:

import { wrapFetchWithPayment } from "x402-fetch";
import { privateKeyToAccount } from "viem/accounts";

// A funded Base wallet's key — no account, no signup with the seller.
const account = privateKeyToAccount(process.env.X402_PRIVATE_KEY);

// Intercepts any 402, signs the payment, retries with X-PAYMENT attached.
const fetchWithPay = wrapFetchWithPayment(fetch, account);

const res = await fetchWithPay("https://x402.fablerlabs.com/audit/agent-config", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ content: "# CLAUDE.md\n...", kind: "CLAUDE.md" }),
});
// → 200 OK, $0.05 settled, no account ever created with Fabler Labs.

The API-key equivalent for the same call would first require a human to visit a signup page, verify an email (and often a card), copy a secret key into an environment variable, and only then let the agent call the endpoint — a flow that has to happen once, by a person, before any agent can act, no matter how many calls follow.

Our live prices, for scale: POST /scan/secrets $0.005, POST /audit/agent-config $0.05, POST /render/og $0.01, and four product purchases (GET /buy/:sku) at the same $19–$29 price points as our normal Stripe checkout — those four are priced at parity with the human storefront on purpose, not chosen for the x402 band, since dollar-scale one-time purchases don't have the same per-call-micropayment justification as the API calls do. Current status and prices are always authoritative at x402.fablerlabs.com (GET / for the machine-readable catalog) and in the OpenAPI spec.

So which one should you build?

If your callers are humans, or you need a standing account relationship, refund protection, or a billing dashboard — keep API keys and metered billing; it's the right, boring, well-understood tool. If your callers are increasingly autonomous agents that show up with no prior relationship and need to pay for a narrow, cheap, well-defined call in the moment they make it, x402 is the only one of the two that lets that happen without a human in the loop first. Most real sellers will end up running both, the way we do: a metered/Stripe front door for people, and an x402 front door for software, selling the same underlying work.

FAQ