API / metered-billing revenue estimator
Model MRR for a usage-based or metered API product — and see what the revenue looks like as average consumption per customer scales from today's baseline to 2×, 5×, and 10× growth.
Enter your per-unit price, average monthly units consumed per customer, and total customer count. The scenario table shows how revenue scales as usage grows — useful both for forecasting and for validating whether your pricing holds at higher consumption levels.
API metered billing estimator inputs and results
Usage growth scenarios
| Usage multiplier | Avg units / customer | Rev / customer | Total MRR | vs today |
|---|
How metered-billing revenue scales
Metered-billing revenue is linear in both usage and customer count. Doubling average usage per customer doubles MRR; doubling customers also doubles MRR. This linearity is both the appeal and the risk: when customers grow into the product, revenue grows automatically without any sales motion. But if customers reduce usage — for budget or workflow reasons — revenue falls just as mechanically.
The scenario table shows why early-stage metered products often look small but have large upside. If your current customers are lightly integrated, the 5× and 10× columns represent what the same customer base could generate once fully embedded. This is a common pattern in infrastructure and developer tools: initial usage is exploratory, and revenue per customer grows significantly over the first 12–24 months of the relationship.
Be cautious at the high end: if revenue per customer at 10× usage becomes a large line item for your customers' budgets, you may face pressure to introduce volume discounts or committed-use tiers. Modelling this early lets you design those tiers before customers demand them.
About this tool
This tool estimates MRR for API and usage-based billing products. Inputs: per-unit price ($), average monthly usage per customer (units), current customer count. Output: MRR, ARR, revenue per customer, and a usage growth scenario table at 2×, 5×, and 10× average usage. Formula: MRR = unit price × avg monthly usage per customer × customer count.
Frequently asked questions
How is metered-billing MRR calculated?
MRR for a metered-billing product equals the per-unit price multiplied by the average monthly units consumed per customer, multiplied by the number of customers. Unlike seat-based SaaS where each customer pays a fixed amount, metered revenue scales with consumption — making the average usage per customer the most important variable to model accurately.
Why does this use average usage rather than a distribution?
Using average usage gives a useful first estimate, but the actual revenue distribution in metered products is usually highly skewed — a small number of heavy users often accounts for a large share of revenue. The scenario table models what happens if average usage rises, which could represent either existing customers growing or a shift in your customer mix toward heavier users. For a more precise model, segment your customers into usage bands and calculate revenue per band.
What is a good price per unit for an API product?
There is no universal benchmark — it depends on what a "unit" means in your product and the value each unit delivers. Common unit types include API calls (often $0.001–$0.01 each), processed records ($0.001–$0.05 per row), tokens (sub-$0.001 for LLM products), and transactions (0.1–0.5% of transaction value). The right price is one where heavy users still find the economics comfortable and where your margin at high usage volumes covers your infrastructure costs with a healthy buffer.
How does the 2×, 5×, 10× scenario table help?
For a new API product, your current average usage per customer is often much lower than it will be once customers are fully integrated. The scenario table shows the revenue upside if usage grows, without changing any other variable. It's also useful for stress-testing: if 10× usage would make the product unaffordable for most customers, you may need to introduce volume discounts or a committed-use pricing tier before customers hit that level.