Key Takeaways

• Rate limits and monetization quotas solve different problems. GitHub allows 60 requests per hour unauthenticated and 5,000 with a personal access token, and neither number exists to sell anything.

• A gateway can enforce a limit but can't price one. Turning a limit into revenue needs the request tied to a plan, a customer, and a rate.

• Per-call pricing is the easiest unit to meter and often the worst proxy for value, since one call can return a single field or an entire dataset.

• Scaling rules make limits look like plans without being them: GitHub App installations gain 50 requests per hour per repository past 20 repositories, capped at 12,500 per hour for non-Enterprise installations.

• An API monetization stack has to attribute every request to a customer before it can bill for one, which makes key-to-account mapping the foundation rather than a detail.

What can you charge for in an API product?

Charge for calls, for the work behind the calls, for the data returned, or for the right of access, and pick the one that tracks the value your caller gets.

The units in common use, with what each one rewards:

• Per call. Simple to meter and simple to explain. Punishes efficient integrations and rewards chatty ones.

• Per unit of work. Records parsed, pages processed, minutes transcribed. Tracks your cost more honestly than call count.

• Per data volume. Bytes or rows returned. Fits read-heavy APIs where response size drives your cost.

• Per successful result. Only billable outcomes count, so failed calls are free. Harder to define, easier to sell.

• Per seat or per key. Access pricing with a volume ceiling attached, which suits internal enterprise integrations.

Per call wins on legibility, which is why so many APIs launch there. The problem surfaces later: a customer who batches 1,000 records into one request pays a thousandth of what a customer sending them one by one pays, for identical work.

How do rate limits differ from monetization quotas?

A rate limit protects your infrastructure; a monetization quota protects your revenue. They look alike and they're enforced in different places for different reasons.

GitHub's REST API shows limits set purely for capacity:

Those numbers scale with installation size rather than with a plan, which makes them capacity provisioning, not a price ladder.

A monetization quota is tied to the plan the customer bought, resets on the billing cycle rather than the hour, triggers a charge or a block rather than a retry, and reconciles against an invoice at period end. Enforce one in a gateway alone and you get a customer who's been throttled but never billed.

What does an API monetization stack need to track?

It needs to resolve every request to a customer, a plan, and a priced unit, in that order, before the period closes.

The pieces that have to be in place:

1. Key-to-account mapping. Every API key resolves to a billable customer, including keys created after the plan was assigned.

2. Request attribution. Each call is recorded against that customer with enough detail to price it, which for work-based units means capturing the quantity, not just the event.

3. Entitlement checks. Whether this plan may call this endpoint at all, answered in the request path fast enough not to matter.

4. Quota state. How much of the included volume is consumed, available in real time rather than at invoice generation.

5. Overage handling. What happens at the ceiling: charge, throttle, or block, decided per plan rather than globally.

6. Reconciliation. Gateway logs matched against the billing engine quantities, since the two drift and the difference is either lost revenue or an overcharge.

I'd build attribution before pricing sophistication. A stack that meters one boring unit accurately beats a clever model built on request counts nobody can tie back to an account.

Related reading

Further reading on pricing and metering an API:

• how to monetize api calls and track usage metrics is the practical build for charging per call.

• best platform for usage based pricing for api products compares tooling for API products.

• how to track api usage for billing in real time covers metering requests as they happen.

• best billing infrastructure for high volume api transactions handles the scale question.

• where to find usage based pricing tools for ai api traffic covers tooling for AI API traffic.

FAQ

Is API management the same as API monetization?

No. API management handles the operational surface: routing, authentication, versioning, rate limiting, and documentation. API monetization handles the commercial surface: plans, entitlements, metered quantities, and invoices. A gateway is necessary for monetization and nowhere near sufficient, because it knows about keys and requests while billing needs customers and priced units.

Should you charge per API call or per seat?

Charge per call when your cost scales with volume and per seat when it doesn't. Seat pricing suits APIs consumed by a fixed team through an internal tool, where call volume stays roughly flat. Call pricing suits APIs embedded in a customer's own product, where their growth drives your cost and seat count stops meaning anything.

How do you enforce API quotas by plan?

Check entitlement and remaining quota in the request path, then meter the request asynchronously. The synchronous check answers whether this call is allowed under this plan right now, which needs current quota state rather than a nightly rollup. The metering can lag slightly, as long as it reconciles against the gateway's own counts before the invoice generates.

Can you monetize a free API later?

Yes, but you need per-account usage history for the customers you're about to charge, and most free APIs never collected it. Meter for a full billing period before you charge, then set included volumes from the real distribution rather than guessing at the boundaries.