// learn · Data & tools
x402: paying per API call
Market data is where most bot projects hit a wall: the free tier is too thin, the paid tier is a monthly subscription you barely use. x402 is an attempt at a third option, paying a fraction of a cent per request, with no account at all.
The idea, in one paragraph
HTTP has always had a status code reserved for this: 402 Payment Required, defined decades ago and left unused because there was no way to settle a payment of half a cent. x402 fills that gap. Your client requests a resource, the server answers 402 with the price and where to pay, the client pays in a stablecoin and retries with a proof of payment, and the server returns the data. No signup, no API key, no card on file, and it works the same whether the caller is a person or a program.
Why it matters if you build bots
- Cost tracks usage. A scanner that runs every six hours pays for those calls only, not for a monthly plan sized for its busiest week.
- No onboarding per provider. Trying five data sources normally means five signups, five keys, five billing relationships. Here it means five requests.
- Agents can pay for themselves. A program with a funded wallet can buy the data it needs at runtime, which is the actual reason this protocol exists now and not in 2015.
- It works in the other direction too. If you have data worth paying for, the same mechanism turns an endpoint into a product without building billing, accounts or invoicing.
What to weigh before using it
This is young infrastructure. The honest comparison is not "x402 versus subscriptions" in the abstract, but these variables against your actual call pattern.
| Variable | Why it decides the answer | Where it goes wrong |
|---|---|---|
| Calls per month × price per call | The only fair comparison against a flat subscription | High-frequency polling: per-call quickly costs more |
| Settlement cost and chain | A micropayment is pointless if the fee exceeds it | Only viable on low-fee chains; fees are not fixed |
| Added latency per request | Payment and verification sit inside your request path | Latency-sensitive strategies cannot absorb it |
| Hot-wallet exposure | Your bot holds spendable funds continuously | A compromised host now drains money, not just data |
| Spend limits and a kill switch | A retry loop is now a loop that spends | No per-day cap means one bug empties the wallet |
| Provider count and data quality | Easy payment does not make a feed accurate | Thin ecosystem; established APIs still win on coverage |
| Accounting and tax treatment | Thousands of stablecoin payments are taxable events in some jurisdictions | Records you must keep, unlike one monthly invoice |
Reality check
x402 is a payment rail, not a data source and not an investment. There is no x402 token to buy, and any token marketed as one deserves the red-flags checklist. Treat it as plumbing you might use while building, alongside the free APIs in our market-data APIs guide, and the bot patterns in build a bot. If your wallet is funding it, read smart-contract safety first.
Educational market information, not financial advice. Markets carry risk of loss, do your own research.