API Rate Limiting, Throttling and Quotas Explained

By Grocito17 October 2026

API rate limiting caps how many requests a caller can make in a given period so that no single user, script or bug can slow the service for everyone else. Throttling slows callers down instead of rejecting them, and a quota is a longer-term allowance, such as a monthly total. Used together, they protect stability, fairness and cost, and they give you a clear way to define plans.

Key takeaways

Limits protect against abuse, accidents and unfair use, and they keep your infrastructure bill predictable.
Rate limit, throttle, quota and burst are different ideas. Decide which of them each endpoint actually needs.
Token bucket suits most business APIs because it allows short bursts while holding a steady average.
Enforce limits as early as practical, per key, user or tenant, and add tighter limits on login and costly endpoints.
Tell clients what the limits are through documentation, response headers and a clear error that says when to retry.
Watch for denied requests in monitoring, because a rising count is either an attack or a customer you should talk to.

Why do APIs need limits at all?

Without limits, your API's capacity is shared on a first-come basis, and the loudest caller wins. Four reasons come up repeatedly.

Abuse. Credential stuffing, scraping and brute-force attempts all rely on sending many requests quickly.
Fairness. One customer running an enthusiastic import should not make the service slow for everyone else.
Cost. Some endpoints trigger database-heavy reports, file processing or paid third-party calls. Unlimited access to them is an open tap on your costs.
Stability. A client with a retry bug can generate a flood of traffic that looks like an attack. Limits turn a possible outage into a contained problem.

What is the difference between rate limit, throttling, quota and burst?

These words are often used loosely, so agree on definitions within your team.

Rate limit: a maximum number of requests in a short window, for example per second or per minute. Requests above it are refused.
Throttling: slowing or queueing requests instead of refusing them outright. The caller still gets an answer, just later.
Quota: a longer-term allowance, such as requests or records per day or per month, often tied to a pricing plan.
Burst: a short spike above the usual rate that you choose to allow, because real traffic is uneven.

A typical design combines them: a steady rate, a modest burst allowance, and a monthly quota that matches the customer's plan.

How do the common rate limiting algorithms work?

You do not need formulas to choose well. Here is how each behaves in plain words.

Fixed window

Count requests in each clock window, such as each minute, and refuse anything over the limit until the next window starts. It is simple and cheap. The weakness is the boundary: a caller can send a full allowance at the end of one window and another at the start of the next, producing a short double burst.

Sliding window

Instead of resetting on the clock, look back over the last stretch of time from each request. This smooths out the boundary problem and feels fairer, at the cost of a little more bookkeeping.

Token bucket

Imagine a bucket that refills with tokens at a steady pace, up to a maximum. Each request spends a token. If the bucket has tokens, the request goes through, so short bursts are allowed. If it is empty, the caller waits or is refused. This is the most popular approach for business APIs because it matches how real clients behave: quiet for a while, then busy for a moment.

Where should you enforce limits?

Enforce limits in layers, because each layer catches something different.

CDN or edge: blocks floods and obvious bot traffic before it reaches you. See our guide to content delivery networks for how the edge fits into the picture.
API gateway or reverse proxy: a good central place for per-key limits, because every request passes through it.
Application code: needed for rules that depend on business context, such as a limit per tenant, per user role or per costly operation.

Then decide what the limit is attached to.

Per IP address: easy but blunt. Offices and mobile networks share addresses, so you may block innocent users.
Per API key or token: the best default for server-to-server APIs, because it identifies the customer.
Per tenant or account: essential in shared platforms so one customer's many users cannot exceed the plan.

How should you communicate limits to clients?

A limit that surprises people is a support ticket. A limit that is explained is just a rule.

Document it. State the limits per plan, how they are counted and what happens when exceeded.
Return a clear status. The standard response for too many requests is status code 429. Include a message in plain language and a machine-readable error code.
Say when to retry. Add a Retry-After header, and where you can, headers that show the limit, the remaining allowance and the reset time. Naming conventions differ, so document yours.
Give retry guidance. Tell developers to wait and retry with increasing delays, not to hammer the endpoint.

What should well-behaved clients do?

Back off with jitter. After a refusal, wait, then retry with longer gaps and a little randomness so many clients do not retry in lockstep.
Cache and batch. Do not refetch rarely changing data, and use bulk endpoints where they exist.
Respect the headers. Slow down as the remaining allowance falls, before hitting zero.
Avoid polling when you can. Webhooks cost fewer requests.

How do plans and tiers use limits?

Limits become pricing levers when mapped to plans: a low rate and small quota for free tiers, more generous allowances for standard plans and negotiated limits for enterprise customers. Make sure internal systems can raise a customer's limit without a code release.

How do you protect login and costly endpoints?

Not every endpoint deserves the same limit. Treat these separately.

Login, password reset and verification codes: apply tight limits per account and per address, with increasing delays after failures. Pair them with the practices in our API security checklist.
Search, exports and report generation: apply lower limits or concurrency caps, because each call does heavy work.
Public, unauthenticated endpoints: the strictest limits, since you know least about the caller.

What are the caveats of distributed counters?

If your API runs on several servers, each cannot keep its own count, or a caller gets the full allowance on every server. Most teams keep counters in a shared fast store. That adds a dependency, so decide what happens if it is unavailable: allow traffic (fail open) or refuse it (fail closed). Failing closed is safer for login, and failing open is usually kinder for general reads. Accept that limits across regions are approximate: slightly loose is fine, blocking good customers is not.

How do you monitor and handle legitimate spikes?

Track denied requests, which keys hit limits and which endpoints are affected. Alert on sudden jumps and review top offenders weekly. Some will be attackers, some buggy clients and some happy customers who have outgrown their plan, which is a sales conversation.

For legitimate spikes, such as a marketing campaign or a customer's end-of-month batch run, agree temporary higher limits in advance, allow generous bursts, or offer a bulk or asynchronous endpoint for heavy jobs. See our guide to monitoring and observability for setting up the dashboards.

How do you test rate limits?

Write automated tests that exceed the limit and check the refusal, status code, headers and reset. Confirm that one customer's traffic cannot use another's allowance, and test the failure mode of your counter store on purpose.

Common mistakes to avoid

Limiting only by IP address and blocking shared offices.
Returning a generic server error instead of a clear refusal with retry guidance.
Applying one limit to every endpoint, regardless of cost.

A worked example

Imagine a logistics company whose API serves shipment tracking. One partner's script polls every second for thousands of parcels, and tracking slows for everyone. The company adds a token bucket per API key, a lower concurrency cap on bulk exports, a clear refusal with a retry hint and published limits per plan. It also offers webhooks, the partner switches from polling and the problem disappears.

FAQ

What is the difference between rate limiting and throttling?

Rate limiting refuses requests once a caller exceeds an allowance, usually with a 429 response. Throttling slows or queues requests so that they are still served, only later. Many systems use both: throttle gently first, then refuse when a hard limit is passed.

What is the best rate limiting algorithm for a business API?

Token bucket is a strong default because it allows short bursts while keeping the long-run average steady, which matches how real clients behave. Sliding window is a good alternative when you want very even enforcement. Fixed window is the simplest but can allow a double burst at window boundaries.

Should I rate limit by IP address or by API key?

For authenticated APIs, limit by API key, user or tenant, since that identifies who is responsible. Use IP limits as an extra layer for public and login endpoints. IP-only limits can wrongly block many people who share one office or mobile network address.

What should an API return when a limit is exceeded?

Return status code 429 with a clear message, an error code and a Retry-After header so the client knows when to try again. Documenting the behaviour matters as much as the response itself, because it lets developers handle it gracefully.

Next steps

List your endpoints and mark which are cheap, expensive or sensitive. Set a sensible default limit, tighter limits on login and heavy exports, then publish the rules and watch the denied-request numbers for a few weeks. If you would like help designing limits for a new or existing platform, see our API development services, compare approaches in REST vs GraphQL, or contact us to talk it through.