How to price an API product

API products have a pricing advantage most software does not: usage is already measured. Every call hits your servers and gets logged. The hard part is not metering, it is choosing what to charge for and how to shape the curve. The decisions below come up in this order for almost everyone.

Choose the unit customers can control

The billable unit should be something the customer can see, predict, and influence. Per request is the default for a reason: developers can count their own requests. Units like compute seconds or internal work units are accurate for you but opaque for them, and opaque units generate disputes.

If different endpoints cost you wildly different amounts, resist inventing a mystery unit. Either price the expensive endpoints separately, or use a credit system where each endpoint's burn rate is published. Both keep the meter legible.

The free tier is marketing, priced in units

Almost every successful API has a free tier, and the honest way to think about it is as a marketing budget denominated in requests. Make it big enough that a developer can build and demo something real, small enough that production traffic has to pay. A monthly allowance (say, the first 10,000 requests free) does this cleanly, and it renews goodwill every month.

Shape the curve: tiered, volume, or stepped

Past the free tier, per unit prices usually fall with scale. There are three standard shapes, and they produce different invoices for the same usage:

• Tiered: each band bills at its own rate, so early units always cost more. Rewards growth gradually.
• Volume: the whole quantity bills at the landing band's rate. Simpler, friendlier to big customers, but crossing a boundary can drop the total bill, which looks odd on a graph.
• Stepped: the band sets one flat price for the whole quantity. The most predictable invoice of the three.

We wrote a longer piece on these shapes with worked numbers in usage based pricing examples. Pick one deliberately; the differences are real money at scale.

Commitment is where the real revenue is

Self serve pay as you go gets you adoption. Committed use gets you a business. Once a customer's monthly bill stabilizes, both sides usually prefer a deal: they commit to a term or a minimum, you give a better rate. Your billing system needs to represent that commitment as a first class thing (a contract term on the subscription, not a spreadsheet note), so renewals, upgrades, and the invoice all respect it.

The mechanics developers will judge you on

Developers are your buyers, and they will inspect the meter like they inspect an API response. Three things earn their trust:

1. Usage they can query. Current period usage should be visible before the invoice exists, not revealed at month end.
2. Bills that reconcile. The invoice should show the counts, the bands, and the per band math. If their own logs say 1.2 million requests and your invoice cannot show how 1.2 million became $840, you will be exchanging emails.
3. Exact arithmetic. At fractions of a cent per request, rounding per event or computing in floating point produces drift that sharp customers will find. Compute exactly, round once per line.

This is the part yRecurring is opinionated about. Metered prices cover tiered, volume, stepped, package, and per unit shapes, usage is recorded against meters you define, contract terms live on the subscription, and every amount on every invoice carries a receipt: the counts, the bands, the formula, the single rounding step. When a developer customer asks how 1.2 million requests became $840, the answer is a link.

Start simpler than feels impressive

The most common mistake is overbuilding. Launch with one unit, one curve, and a free tier. You can add committed use when the first customer asks for it, and credits when usage gets spiky. Pricing models are easy to add later and painful to retract.

If you want to model your API's pricing and see the invoices it would produce, the trial lets you enter your bands and read the resulting invoice, receipt and all.