stelar digital · pricing an api for agents

How pricing works for AI-agent-paid APIs

Part of our x402 series: guide · pricing · vs RapidAPI · start here · quickstart · state of x402

Live mechanics, and what settled and what didn't on our own endpoints — re-checked today.

Pricing for a machine buyer isn't a discount version of pricing for a human. There's no sales call, no annual-plan upsell, no "talk to us for enterprise pricing." An x402 (the HTTP-402-based payment protocol explained on the x402 guide) response carries one machine-readable price field, and the calling AI agent (software, often built on a large language model, that carries out a task on its own) decides whether to pay it through its own task logic, calling our API (a web address one program calls to get data or trigger an action from another) directly. Here's how that field works, and what we measured running it on our own API.

What a "price" is inside a 402 response

When an unpaid request hits one of our endpoints, the response is an HTTP 402 with an accepts list: one entry per network our own API accepts payment on (Base on every route, plus Solana on three of them), naming the stablecoin asset and the exact amount required in that asset's smallest unit, plus the wallet address to pay. We also run a second, separate host on Algorand, with its own payment challenge. There's no separate checkout page, no plan selector — the number in that field is the entire negotiation. Pay it, retry the same request with proof attached, get the real response.

Two shapes: the single fact and the bundle

We price our raw, single-purpose data calls (a grid-sizing recommendation, a market-regime read, a price check) each at a very small per-call price — they're not uniform, the protocol has no fixed tiers, and our grid-sizing call in particular costs about ten times our cheapest single-purpose route — and we also built two combined bundles that fold four calls' worth of signal into one request, priced well above any of the raw calls, on the theory that convenience justifies the premium.

What actually settles

Per our own receipts log (checked today): out of 84 settled calls on our primary rail, the six raw, single-purpose endpoints account for 82 of them. The two combined bundles account for two settled calls between them — one each — despite being live and discoverable in the same catalog the whole time. That's a real, lopsided split we can point to, not a theory: buyers overwhelmingly choose the cheap atomic fact over the combined tier, even when the bundle is objectively a better deal per underlying call.

Why machine pricing behaves differently from human pricing

A human evaluating a pricier bundle weighs it against the time it would take to gather the same information manually — that's the whole logic behind "convenience" pricing, and it works on humans constantly. An agent executing a task doesn't have that calculus. It has a budget, a goal, and a decision function that's usually optimizing for cost-per-unit-of-useful-signal, not cost-per-minute-saved. When the same fact is available cheaply on its own and bundled at a premium with three other facts from another source, the cheaper atomic unit wins even if the bundle is a better deal on paper — because nothing in the agent's loop is pricing in its own "time," the way a human would price in theirs.

That's also why per-call microprices aren't a race to the bottom the way discounting is for human SaaS. There's no customer-acquisition cost to recover with a higher price point, no sales team to fund, no annual contract to protect. The economics of an agent-facing endpoint look more like a utility meter than a subscription: usage-based, small, and only valuable in aggregate if buyers come back.

What we measured on discovery vs. settlement

Our catalog and MCP listings get checked constantly — discovery crawlers, registry indexers, and agent frameworks probing what's available run in the dozens-per-day range on our own logs, most of it unauthenticated handshake traffic rather than paid calls. That's normal and worth knowing before you panic about "low conversion": most of what hits a freshly listed endpoint is infrastructure noise, not a buying decision. The only number we treat as signal is settled activity, which is why every figure on this page traces back to receipts we can point to, not request logs.

Rules we'd give another builder

• Start at a very small per-call price for a raw data call. The registered x402 catalog we checked today lists more than 17,000 endpoints, and the ones we've sampled over time skew heavily toward inexpensive single calls, not premium bundles — which matches what settles for us.
• Price the atomic fact, not the convenience bundle. If you have five data points, price access to each one separately before you build a "premium" combined tier. Our own settlement data says the combined tier is the thing that barely sells.
• Don't confuse a low price with low revenue potential. A wallet that returns repeatedly is worth more over a quarter than one large purchase that never repeats. Optimize for repeat settlement, not per-call size.
• Publish your real numbers. We publish our own settlement activity ourselves, live at /open. It's a small number. It's also one of the only numbers in this space that isn't a projection.

Source for our own figures: our production receipts log on api.stelardigital.com, checked 2026-09-27. Catalog-scale reference: Coinbase's CDP x402 discovery catalog, queried the same day — see /state-of-x402 for the full census and method.

Not financial advice. Any trading-related figures on this page reflect our own retired account. See our Disclaimer.