If your product exposes an API, or leans hard on one, rate limiting stops being a “nice to have” the moment real customers show up. This guide is for founders and CTOs who are about to ship an API (or have already shipped one without much thought to limits) and want a practical grounding in API rate limiting best practices before an integration partner, a bug, or a bad actor takes the whole platform down. You’ll get the core algorithms explained in plain English, guidance on what to limit and where, and how to design limits that match your pricing model rather than fighting it.
Why API rate limiting best practices matter once you have real users
Most teams add rate limiting reactively, after an incident: a partner’s retry loop hammers an endpoint, a scraper finds an unauthenticated route, or one noisy customer’s integration starves everyone else’s requests. By then you’re firefighting in production rather than making a considered design decision.
Rate limiting does three jobs at once. It protects your infrastructure from being overwhelmed, whether that’s a database connection pool or a downstream provider you’re billed per call for. It keeps usage fair across customers on a shared system, so one tenant’s misbehaving script doesn’t degrade service for everyone else. And it gives you a lever to align technical usage with your commercial plans, which matters as soon as you charge by volume or tier features by plan.
The main rate limiting strategies, in plain English
There’s no single “correct” algorithm; each makes a different trade-off between accuracy, memory cost, and how it handles bursts of traffic.
- Fixed window counts requests in, say, each calendar minute and resets to zero at the boundary. It’s simple to implement and reason about, but it has a known weakness: a client can send a full quota’s worth of requests in the last second of one window and another full quota in the first second of the next, doubling the effective rate briefly.
- Sliding window tracks requests over a rolling period rather than a fixed clock boundary, which removes that edge-case burst. It costs a little more to compute and store, but it’s the right choice when you need a genuinely strict “100 requests per minute, no exceptions” rule.
- Token bucket gives each client a bucket of tokens that refills at a steady rate; every request spends a token, and requests are rejected once the bucket is empty. This is the most common choice for API rate limiting because it allows short, legitimate bursts (a user importing a batch of records, say) while still enforcing an average rate over time.
- Leaky bucket is the token bucket’s mirror image: requests queue up and are processed at a constant rate, smoothing bursts rather than allowing them. It suits situations where you need predictable, even load on a downstream system more than you need to be generous about spikes.
For most SaaS APIs, token bucket per API key is a sensible default, with sliding window reserved for security-sensitive endpoints such as login or password reset, where you want a hard, predictable ceiling rather than any burst allowance.
Deciding what to limit
Rate limits usually need to operate on more than one axis at once:
- Per API key or account — the baseline for any authenticated API, and the natural place to attach different limits per pricing tier.
- Per IP address — a backstop for unauthenticated endpoints, login attempts, and anything a script could hit before it even has credentials.
- Per endpoint — a search or export endpoint that hits your database hard deserves a tighter limit than a lightweight status check, even for the same customer.
- Per resource — file uploads, bulk exports, and anything that fans out to a third-party API you’re billed for should usually have its own, stricter ceiling, separate from your general request limit.
If you’re already integrating third-party APIs into your product, it’s worth reading our guide on third-party API integration costs alongside this one — the same volume-based thinking that controls your spend on outbound calls should shape the limits you set on your own inbound API.
Where to enforce limits: gateway or application code
You broadly have two places to put this logic. An API gateway (whether a managed product or something you run yourself) can enforce limits before a request ever reaches your application, which is the cleanest place to stop abusive traffic and keep the policy in one location rather than scattered through your codebase. It’s the right default for anything internet-facing.
Application-level limiting, typically backed by Redis for its atomic increment-and-expire operations, gives you more nuance: limits that vary by subscription plan, by feature flag, or by the specific action a user is taking rather than just the route they hit. In practice, most mature APIs use both — a coarse gateway limit as a blunt safety net, and finer application-level limits that understand your actual business logic.
Whichever layer you choose, make the limiter’s state shared across every instance of your service. A per-process in-memory counter looks like rate limiting in a demo and does nothing useful the moment you run more than one server behind a load balancer.
Designing limits around your pricing model, not against it
Rate limits and pricing should tell the same story. If you charge per seat, limits are usually set per account and can be generous, since abuse risk is lower than in a usage-based model. If you charge per API call, or offer a free tier that upgrades into a paid one, your limits effectively are your pricing enforcement — get them wrong and you either give away paid capacity for free or throttle paying customers into churn.
This is the same territory we cover in our SaaS payment integration guide: usage-based billing and usage-based rate limiting need to be built from the same source of truth, ideally the same metering data, so a customer’s invoice and their actual throttling always agree with each other.
Give developers a good experience when they hit a limit
How you communicate a rate limit matters almost as much as the limit itself, especially if other companies are integrating against your API. Return a standard 429 Too Many Requests status rather than a generic error, and include headers such as X-RateLimit-Limit, X-RateLimit-Remaining, and Retry-After so well-behaved clients can back off automatically instead of guessing.
Document your limits clearly, including any burst allowance, and be consistent about where they apply. Integration partners will build retry logic around whatever you publish, and quietly changing limits without warning breaks those integrations in the same way an unversioned API change does — a problem we go into in more detail in our webhook reliability guide, since webhooks and rate-limited APIs fail in similar, retry-driven ways when the contract isn’t clear.
Mistakes we see most often
The most common failure isn’t picking the wrong algorithm, it’s having no visibility into what your limits are actually doing. Teams set a number, ship it, and never look again — until a customer complains they’re being throttled, or an incident reveals the limit was never actually being enforced in production. Track rate limit hits, near-misses, and rejections the same way you’d track any other operational metric; our piece on observability for startups covers the broader monitoring foundations this depends on.
The other recurring mistake is treating rate limiting as purely defensive. Used well, it’s also a product signal — a customer consistently hitting their ceiling is a customer ready to be upsold onto a higher tier, not just a support ticket waiting to happen.
If you’re building or hardening an API and want a second opinion on where your limits should sit, book a free consultation and we’ll talk through your traffic patterns and pricing model together.
FAQ
What’s the difference between rate limiting and throttling?
They’re often used interchangeably, but rate limiting typically rejects requests once a quota is exceeded, while throttling delays or queues them to smooth out load. Many APIs use a mix of both: a hard rate limit as the outer boundary, with throttling to manage traffic within it.
Should I rate limit by IP address or by API key?
Use API keys wherever a request is authenticated, since that’s tied to a real account and lets you set limits per plan. Reserve IP-based limits for unauthenticated endpoints, such as login or signup, where there’s no key yet to attach a limit to.
What HTTP status code should a rate-limited request return?
Return 429 Too Many Requests, along with a Retry-After header telling the client how long to wait. This is the standard clients and libraries expect, and it lets automated retries behave sensibly instead of hammering your API immediately again.
Do I need rate limiting if I’m not worried about abuse?
Yes. Even with entirely well-intentioned users, rate limiting protects you from your own bugs, from a partner’s misconfigured retry logic, and from one customer’s legitimate spike in usage degrading service for everyone else on shared infrastructure.
Related: REST vs GraphQL: A Founder’s Guide to API Architecture — if you’re setting rate limiting policy, it helps to first be clear on which API style you’re building for.
