Why API pricing drifts away from usage
API products often launch with simple plans: a hobby tier, a pro tier and "contact us" for big users. Usage then grows unevenly. A handful of accounts send most of the traffic and pay a flat price, while small accounts pay for capacity they never touch. Infrastructure costs follow usage, revenue does not, and margin shrinks quietly.
Monetisation puts usage per account next to revenue per account and shows where pricing has drifted. It then estimates the effect of tier changes, overages and licences before you ship anything.
The revenue streams that matter for API and data businesses
- Usage tiers. Plans with an included monthly volume of calls, records, tokens or jobs.
- Overages. The price per unit above the included volume.
- Rate limit tiers. Requests per second or concurrency as a plan boundary.
- Premium features. Higher accuracy models, webhooks, dedicated support, longer data retention.
- Data licensing. Bulk datasets, historical archives and licences for specific uses.
- Annual commitments. Yearly plans with a volume commitment and a lower unit price.
What the audit typically finds for an API or data company
The examples below are hypothetical. Your audit shows only what your own data supports, each with an estimate range, a confidence level and the method next to it.
Top accounts on flat prices
When the top 5 percent of accounts make 60 percent of the calls and pay a flat plan price, the audit estimates a usage tier or overage that brings their revenue closer to their usage. The usage based pricing page explains the method.
Overages priced below the next tier
If paying overages is cheaper than upgrading, customers stay on the small plan and pay overages forever, often at a price below your own cost. The audit compares overage price with the effective unit price of each tier.
Rate limits that do not separate plans
When every plan has the same rate limit, production users have no reason to move up. The audit reads request patterns and estimates a rate limit boundary that matches how heavy users actually work.
A free tier that feeds no one
A generous free tier can bring in many accounts that never pay. The audit measures how many free accounts convert and whether a smaller free allowance, or a paid starter tier, would earn more.
Data that could be licensed
Companies that hold unique, structured data, such as historical records or aggregated signals, sometimes sell only API access when a bulk licence would suit some buyers better. The audit flags this as a playbook with an estimate built on the assumptions you set.
Data sources to connect
| Source | What it gives the model |
|---|---|
| Stripe | Plans, overages billed, MRR, churn, expansion, annual share |
| Product database (read-only) or CSV of usage events | Calls, records or units per account per day |
| Your website (crawl) | Pricing page, plan limits, documentation of rate limits |
| Google Analytics 4 | Traffic to pricing and documentation, signup funnel |
| HubSpot or Salesforce | Negotiated contracts and committed volumes |
Usage data usually comes from a read-only connection to the product database or a daily CSV export from your gateway. Growth includes 10 sources and Scale adds API access and webhooks, so you can push results into your own systems.
A worked example, entirely hypothetical
Take an API with three plans. Hobby at 0 USD includes 1,000 calls. Pro at 49 USD includes 100,000 calls. Business at 299 USD includes 1,000,000 calls. There are no overages: requests above the limit are refused. 600 accounts are on Pro and 80 on Business.
Current MRR: (600 × 49) + (80 × 299) = 29,400 + 23,920 = 53,320 USD.
Usage data shows that 150 Pro accounts hit their limit every month, and 20 Business accounts use over 2,000,000 calls through extra keys.
| Opportunity | Method in plain words | Estimated monthly impact (low, expected, high) |
|---|---|---|
| Overage on Pro at 0.60 USD per 1,000 calls | 150 accounts average 40,000 extra calls, 25 percent of that volume assumed to disappear once it costs money | 1,800, 2,700, 3,600 USD |
| Business overage at 0.25 USD per 1,000 calls and one key per account | 20 accounts average 1,200,000 extra calls, 10 percent reduce usage | 3,800, 5,400, 6,000 USD |
| Hobby limit reduced from 1,000 to 500 calls with a 19 USD starter plan | 3 percent of 4,000 active hobby accounts move to starter | 1,000, 2,300, 3,400 USD |
The Business overage arithmetic, expected case: 20 accounts × 1,200 thousand extra calls × 0.25 USD is 6,000 USD, minus 10 percent for accounts that cut usage, which leaves 5,400 USD. The Pro case: 150 × 40 × 0.60 USD is 3,600 USD, minus 25 percent, which leaves 2,700 USD. The hobby case: 4,000 × 3 percent = 120 accounts at 19 USD is 2,280 USD. Every figure is an estimate, never a guarantee of results.
The Pro overage price of 0.60 USD per 1,000 calls is set above the effective unit price inside Business (299 USD for 1,000,000 calls is about 0.30 USD per 1,000), so heavy Pro users still find upgrading cheaper. The audit shows that reasoning in the method.
How experiments run for an API business
Pricing page variants
On Growth and Scale, the snippet shows variants of your pricing page, with a holdout group that sees the current version. Typical tests: overage shown in the plan card or in a footnote, yearly default, a calculator for expected monthly cost.
Dated interventions
Overage prices, new tiers and rate limit changes are made in your own billing and gateway. You record the date, and Monetisation compares revenue per account, upgrades and churn after that date with the trend from your baseline period, then shows lift and an interval.
Playbooks
Launching a data licence or moving contracts to annual commitments is a sales and legal project. Monetisation gives you a checklist and tracks the metric you choose.
Each result has a verdict: win, flat, loss or not enough data. Losses appear in the report alongside wins.
Where to read more
For the reasoning behind each model, from free tiers to data licences, read the API monetization strategy article. If your API sits inside a broader SaaS product, the SaaS pricing optimization page covers plans, seats and annual billing. Platforms that take a share of transactions between partners should also see marketplace take rate optimization.
Monetisation reads usage and billing data read-only, never changes prices or charges in a connected account, and does not use your data to train AI models.
Getting started
Run a sample audit on the homepage with your API's website and the API or data business type. You see the first 3 opportunities with estimate ranges and a revenue stack map in about a minute, with no card. To connect usage data and Stripe, see pricing and get started.
Questions
What is the best pricing model for an API?
Most API businesses use tiers with an included monthly volume and an overage price above it. Pure pay per call suits occasional users, flat plans suit predictable workloads, and the hybrid of the two fits most products.
How do I set an overage price?
Set it a little above the per-unit price inside the next tier up, so customers who regularly exceed their plan find it cheaper to upgrade. Then watch how many accounts pay overages each month.
Should rate limits differ by plan?
Yes, rate limits are a natural way to separate plans. Hobby use needs few requests per second, while production workloads need more and usually pay more for it.
What is data licensing?
It is selling the right to use a dataset, often in bulk or for a specific purpose such as research or model training, under a licence with terms. It suits companies that hold unique, well-structured data.
Does Monetisation meter my API?
No. Your API gateway or product database keeps metering. Monetisation reads usage per account read-only, models revenue and estimates pricing changes, and it never changes prices or charges in a connected account.
See what your own site is leaving on the table
A sample audit reads your public pages and returns the first three opportunities with estimates and methods. About a minute, no card.