How to Price an API: Cost, Margin, Usage and Billing Models

Before choosing a price, decide what the customer is really buying. A paid API may sell requests, records, tokens, credits, generated files, fraud checks, enrichments, or access to a workflow. Pricing becomes confusing when the public plan says one thing while the infrastructure cost is driven by another. If customers pay per request but your cost is mostly output tokens, long responses can quietly destroy margin.

The safest first step is to write the pricing unit, cost driver, and customer value side by side. For a geocoding API, one request may be the unit and the value is a resolved address. For an AI API, the value may be an answer, but the cost driver is usually input tokens, output tokens, cache behavior, tools, and retries. A good price makes those three concepts line up closely enough that customers understand the bill and heavy users remain profitable.

Competitive research matters, but it should not be the first spreadsheet. Start with a cost-plus calculation so you know the minimum sustainable price. The core formula is: required revenue = total delivery cost / (1 - target margin - payment fee - refund rate - bad debt rate). This converts cost into the revenue needed to keep the intended margin after percentage-based losses.

Suppose an API costs $2,000 per month to deliver at expected volume. You want a 55% gross margin, expect 4% payment fees, and reserve 3% for refunds and bad debt. The denominator is 1 - 0.55 - 0.04 - 0.03 = 0.38. Required revenue is $2,000 / 0.38, or $5,263. If you expect 100 paid customers, the average customer must contribute about $52.63 per month before you add any extra cushion for support or growth.

After you know the revenue target, choose the billing model. Pure usage-based pricing is transparent for developers and fair for variable workloads, but it can be hard for buyers who need predictable budgets. Subscriptions are easier to approve, but they create risk when a small number of customers use the entire included quota. Hybrid plans often work best for APIs: a base plan includes a useful allowance, and overage keeps heavy usage profitable.

For example, a $49 developer plan might include 100,000 requests, then charge $0.70 per 1,000 extra requests. The included allowance should be priced using expected utilization, not a wishful assumption that every customer will use only 10% of the quota. Stress-test the plan at 25%, 50%, 80%, and 100% utilization. If a plan loses money at realistic utilization, either lower the included quota, raise the price, introduce overage sooner, or narrow the free tier.

A free tier can improve adoption, but it is still a cost center. Price it explicitly. Estimate how many free users will activate, how much each will consume, how much abuse or testing traffic you expect, and what paid conversion rate is needed to fund that usage. A free tier that looks harmless in request counts may be expensive if requests trigger AI output, vendor enrichment, browser automation, or image generation.

A practical free-tier formula is: paid revenue required to fund free usage = free users x free usage per user x unit cost / conversion-adjusted paid user count. If 2,000 free users each consume $0.20 of monthly delivery cost, free usage costs $400. If 80 customers pay, each paid customer indirectly funds $5 of free usage before margin. That may be fine if the product converts well, but it should be visible in the pricing model.

The right API margin depends on how predictable the cost base is. A stable internal database API can work with lower margin than a gateway that resells multiple upstream AI providers. If provider rates change, customers send longer prompts, retry rates grow, or payment disputes increase, a thin margin disappears quickly. The more volatile the API, the more you need margin, alerts, and flexible pricing terms.

Segment margin by customer behavior instead of trusting an average. Light users on a subscription may have excellent contribution profit. Heavy automated users may be profitable only if overage kicks in quickly. Customers who need support, refunds, custom limits, or unusual compliance reviews should not be priced as if they were self-serve low-touch accounts. A healthy pricing system makes the profitable segment obvious and reveals the customers who need a different plan.

A price is only useful if a future teammate can understand why it exists. Record the request volume, token volume, cache hit rate, payment-fee assumption, refund assumption, fixed costs, target margin, and break-even point. When real usage arrives, compare actual numbers against those assumptions instead of arguing from memory.

The fastest way to test the math is to enter the cost, fee, refund, and margin assumptions into the API pricing calculator. Then copy the final model into a short pricing memo: target customer, billable unit, included usage, overage rate, free-tier rules, and the specific condition that would trigger a pricing review.