Setting Rate Limits Without Breaking Your Best Customers

Look at your actual usage distribution before picking a limit: what does a normal, healthy customer on each tier actually do in a day. A limit set from a round number picked in a meeting, a thousand requests a day, sounds reasonable and often has no relationship to what real usage looks like, which means it either throttles normal behavior or does nothing useful at all.

Set the limit at a level comfortably above what your typical good customer needs, with room to grow, and treat repeated limit hits as a signal to look at the account individually rather than an automatic wall.

Revisit the distribution every few months rather than setting it once and assuming it still holds. A limit calibrated against usage from a year ago can quietly become wrong in either direction as your typical customer's usage pattern shifts, either too loose to protect anything or too tight for the product your customers are actually using today.

Real usage is bursty: a customer imports a batch of data, runs a report, then goes quiet for hours. A strict steady-rate limit punishes that entirely normal pattern the same way it would punish a genuine abuse pattern. A token bucket or similar burst-tolerant approach lets a customer use a chunk of their allowance quickly, then refills gradually, which matches how people actually use most products.

This distinction, burst tolerant versus strictly steady, is usually the difference between a rate limit customers never notice and one that generates support tickets every week.

When a customer does hit a limit, a hard error with no context is a worse experience than a clear response explaining the limit, when it resets, and how to request a higher tier if the usage is legitimate. Where possible, degrade service quality instead of cutting it off entirely, slower responses, reduced feature scope, rather than a flat refusal that breaks whatever workflow the customer was in the middle of.

Include the limit and remaining quota in your API response headers so well-built client integrations can self-throttle before hitting the wall, rather than finding out only after a failed request.

A free tier limit exists mostly to prevent abuse and control your own infrastructure cost; a paid tier limit exists to protect shared infrastructure while still giving genuine room to grow. Treating both the same way, or setting the paid tier limit only slightly above the free one, sends a signal that upgrading doesn't actually buy meaningful headroom, which undercuts the reason to upgrade in the first place.

Revisit tier limits as your infrastructure capacity changes; a limit that made sense when you were smaller can become an artificial ceiling on your biggest customers as your infrastructure genuinely scales past what that number assumed.

A single request-per-minute limit applied across your entire API treats a cheap, frequent read endpoint the same as an expensive, rare write or export endpoint. That either throttles legitimate read-heavy usage or leaves the genuinely expensive endpoint under-protected against the exact load pattern it's actually vulnerable to. Set limits per endpoint, or at least per category of endpoint, based on actual infrastructure cost, not a single number that has to compromise for every use case at once.

This is more setup work up front, but it means a customer doing a lot of cheap reads never bumps into a limit that was really meant to protect an expensive export job elsewhere in the API, and the export job stays properly protected instead of hiding behind a limit too loose to matter.

Review each tier's limits against these checks:

• Compare every limit to what a normal, healthy customer on that tier actually does, not to a round number picked in a meeting.
• Allow bursts with a token bucket or similar approach so a batch import does not look like abuse.
• Return a clear response that states the limit, when it resets, and how to request a higher tier.
• Make sure the paid tier gives meaningful headroom above the free tier, or upgrading buys nothing.
• Set limits per endpoint or category so cheap reads and expensive exports are not treated alike.