TL;DR: The monetization stack is three components, not two: a gateway that enforces, a meter that counts, and a biller that charges. The common shortcut — billing from the gateway's rate-limit counter — is the one mistake that reliably produces invoices you cannot defend, because a rate-limit counter is designed to be approximate and to reset, and a billing meter is designed to be exact and to persist.
An API lets you reach customers through channels you do not own. Rather than rebuilding a pipeline, other developers call your endpoints, and you charge for the access. Packaging that properly takes less infrastructure than people expect, provided the pieces are separated correctly.
Who is involved
- API provider: chooses what to expose, owns uptime, pricing and documentation.
- API consumer (developer): calls it under your terms — rate limits, auth, SLAs.
- End user: never sees the API, but uses the product built on it.
Pricing models worth considering
- Subscription: a fixed monthly fee for access and support. Predictable for both sides; leaves money on the table with heavy users.
- Pay as you go: per-call or per-unit — $0.01 per request, $70 for 7,000 calls. Aligns revenue with usage; requires that your counting is trustworthy.
- Hybrid: a base fee with an included allowance and overage above it. Usually the right answer, because it gives the customer the predictability they actually wanted from a subscription.
- Revenue share or ad-free: a percentage of downstream revenue, or a fee to remove limits.
The three components
This is the part most write-ups get wrong by collapsing it into two.
| Component | Job | Optimised for |
|---|---|---|
| Gateway | Auth, routing, caching, rate limits, quota enforcement | Speed and availability. It must decide in microseconds on the hot path. |
| Meter | Counting what was used, exactly once, durably | Correctness. It must still be right months later in front of a customer disputing a number. |
| Biller | Rating, invoices, tax, dunning, payment | Financial completeness and jurisdictional coverage. |
Why you cannot bill from the gateway's counter
It is tempting: the gateway already counts requests per consumer, so why add a meter? Because the two counters have incompatible requirements, and the gateway's is built for the wrong one.
- It resets. A rate-limit window exists to be cleared. A billing period exists to be preserved.
- It is allowed to be approximate. Distributed rate limiters trade exactness for speed, and should — being off by three requests at the edge of a window is a correct engineering trade for a limiter and an unacceptable one for an invoice.
- It is usually in memory. A restart loses the count. For a limiter that is a shrug; for billing it is revenue you cannot recover, because the traffic has passed.
- It has no event identity. No idempotency key means a retried call counts twice, and there is nothing to deduplicate against.
- It keeps no detail. When a customer disputes a total, "the counter said 4.2 million" is not an answer. The question is always which requests, and a counter cannot be un-summed.
This is the same distinction as rate limits, quotas and billing meters being three different counters. Use the gateway to enforce, and emit a separate event to the meter to count.
Enforcing limits at the gateway
With Apache APISIX, or any comparable gateway:
- Per-consumer throttling and quotas via the
limit-countplugin. - Remaining quota exposed in response headers, so customers can see what they have left without asking.
- Separate limits for authenticated and unauthenticated traffic.
Enforcement belongs here because it has to happen before the work does. A billing system finds out afterwards, which is too late to prevent anything — the request has already cost you.
Choosing a biller
It should handle recurring charges, invoices and receipts; subscription, metered and per-transaction models; and multi-currency, tax and the payment methods your geographies need. Stripe, Paddle, Lago and Recurly are the usual shortlist — Paddle if you want merchant-of-record handling for VAT and chargebacks, Lago if you want to stay off any one processor.
One question to ask before signing, because it is invisible until it matters: are prices versioned? If a price edit overwrites the old value, no invoice raised under it can be reconstructed, and every dispute about those invoices becomes unwinnable.
How the three fit together
- The gateway authenticates and enforces, rejecting anything over quota before it reaches your service.
- Your service emits a usage event for work actually performed, with an idempotency key and the dimensions you will want later — consumer, endpoint, and whatever unit you charge on.
- The meter counts idempotently, deduplicates retries, and aggregates into periods.
- The biller rates and invoices from those quantities.
The separation is what lets you change any one of them later. Change the gateway and your billing is unaffected; change the biller and your instrumentation is unaffected. Collapse them, and every change is a re-instrumentation.
Quickstart checklist
- Pick one primary meter and one pricing model. Resist adding a second of either until the first is correct.
- Stand up a gateway with auth and
limit-count, and return remaining quota in headers. - Emit a usage event per unit of billable work, with an idempotency key, and know your dedupe window in seconds.
- Map the meter to a price in your biller, and confirm prices are versioned rather than edited in place.
- Give customers a way to see consumption before the invoice, not only on it.
- Iterate pricing once you can see which endpoints carry the value.
When you are ready to go past the basics, pair this with the Usage API guide and the billing-grade metering architecture.
The gateway's counter layer still needs somewhere fast to live. A plain KV like basekv handles per-API-key counters without the overhead of a relational database — for enforcement, where approximate and fast is the correct trade.