Quota and credits
An allowance of usage attached to an account for a billing period. Credits are a unit of quota that lets different operations cost different amounts.
A quota is how much a customer may consume before they have to pay more or wait for a reset. It is what turns access into a plan.
The first decision is the unit. Counting requests is obvious and often wrong, because a single-record lookup and a large aggregation can differ in cost by orders of magnitude. Credits fix that: a lookup costs one credit, a heavy query costs ten, and the price a customer pays tracks the work you actually do.
The second decision is what counts. Charging a customer for your own HTTP 500 is indefensible. Charging for their malformed 400 is arguable, and tends to generate support conversations worth more than the credit. Counting only successful requests is the version that is simple to state and simple to defend, which matters more than squeezing out every unit.
The third is when it resets. Calendar month, rolling thirty days, or the billing anniversary. Rolling windows are fairer and harder to explain. Pick one, then write it in the documentation rather than leaving customers to infer it.
The fourth is correctness under concurrency. Ten parallel requests against a balance of one credit must not all succeed. A read, decide, write sequence has a race in the middle of it. Use an atomic decrement, or a transaction, and treat this as a correctness requirement rather than an edge case.
Finally, quota state has to be visible to the customer without asking you. “How many credits do I have left” is the most frequent question a metered API receives, and a self-serve usage view removes it from your inbox permanently.
API Indonesia is a live example: credit quotas where only successful requests count, a free tier alongside paid and custom plans, and a dashboard where a customer can see remaining quota against their API key at any time.