x402 makes it technically trivial to set a price for an API endpoint. Working out what that price should actually be is harder, and nobody has written a clear guide to it. This article covers what the current market looks like, how to calculate a sensible floor, common pricing mistakes, and how to think about price discovery when you have no traffic data yet.
The most useful public data on x402 API pricing comes from AgentCash's index of x402-protected endpoints (April 2026). Across their tracked endpoints, the observed median price is $0.028 per call, with a range from $0.002 to $0.440. That range is wide because it spans genuinely different things:
These are early-market prices in a thin market — they'll compress as competition increases. But they give you a sense of where to anchor.
Your floor is the minimum you can charge without losing money on every call. It has three components:
What does it cost you to serve one request? This includes:
Coinbase CDP charges $0.001 per transaction after the first 1,000/month on the free tier. This is a floor contributor — if your endpoint charges less than $0.001, you're paying the facilitator more than you're earning. Factor this in.
For gasless USDC transfers (EIP-3009 on Base), gas is typically absorbed by the facilitator or paid by the client. Verify your facilitator's gas model before assuming this is zero for you.
Your floor = direct marginal cost + facilitator fee + any gas contribution. If your floor calculation comes out above $0.05 per call, reconsider whether the endpoint makes sense to monetise via x402 (micropayment economics stop working at that scale).
Your ceiling is the maximum you can charge before AI agents stop calling your endpoint because it's cheaper to use an alternative, build the capability themselves, or skip it entirely. This is harder to calculate and depends on:
The value of the output. A query that returns data an agent would otherwise spend 30 seconds of LLM inference time generating might be worth $0.10 in agent economics even if it only costs you $0.005 to serve. The gap between your cost and the agent's alternative cost is your margin opportunity.
Agent budget constraints. Most agents operate with per-session or per-task budgets. A single tool call at $0.50 might exhaust a typical session budget in three calls — at which point agents are trained to skip expensive tools. Keeping individual call prices under $0.10 for most endpoints makes your API compatible with a wider range of agent budget configurations.
Competition. If there's a free alternative that does 80% of what you do, your price needs to reflect what the remaining 20% is worth. If you're the only provider of something, you have more room.
You almost certainly don't know the right price before you launch — and neither does anyone else, because x402 is too new for settled market pricing to exist for most endpoint types. The honest approach is to treat pricing as an ongoing experiment rather than a fixed decision.
A practical starting framework:
If your marginal cost is $0.001 and you charge $0.002, you're leaving most of the value on the table. Cost sets your floor, not your price. Price based on value delivered.
At low traffic, it's tempting to price high to cover fixed costs. But high prices suppress the traffic you need to build the usage data that justifies the price. For early-stage APIs, accepting lower margins in exchange for more calls (and more signal about what your users value) is usually the right trade.
Your lightweight lookup endpoint and your heavy compute endpoint shouldn't cost the same. x402 makes it trivial to set different prices per endpoint — use it. Agents will gladly pay $0.10 for a result that would take them $0.30 of inference to generate themselves, but won't pay $0.10 for a simple lookup when there's a free alternative.
If an agent needs to call your API 50 times to complete a task, the per-call price needs to be low enough that 50 calls fit within a typical session budget. $0.005 × 50 = $0.25, which is fine. $0.05 × 50 = $2.50, which will cause many agents to abandon the task or find an alternative mid-session. Think in terms of total task cost, not just per-call cost.
x402's only production-ready payment scheme is exact — fixed price, predetermined amount. This means you can't natively charge based on actual resource consumption (tokens generated, compute time, data returned). Your price is set before the call and can't vary based on what the call actually cost to serve.
For variable-cost endpoints (LLM inference where token count varies, data endpoints where response size varies), your options are:
upto payment scheme (theoretical in V2, not yet production) which would allow variable-up-to-maximum pricingMost current x402 API operators use worst-case or average pricing. Tiered endpoints are emerging as a pattern for endpoints with genuinely wide cost variance.
Market pricing data is from publicly available sources as of June 2026 and will change as the ecosystem matures. This is general business guidance, not financial advice.