What Is API Rate Limiting and How Does It Work?

Your integration worked fine in testing. Then you ran the nightly sync against real data, and halfway through, every request started failing with “429 Too Many Requests”. Now you have half-synced records, an angry operations team and a support ticket open with the vendor.

That’s API rate limiting, and nearly every serious API has it. This guide explains what rate limiting is, why providers use it, how the common algorithms work, and, most importantly, how to build clients that handle limits gracefully instead of falling over.

What API rate limiting is

API rate limiting is a rule that caps how many requests a client can make to an API within a period of time. A limit might be 100 requests per minute, 5,000 per hour or 10 per second, counted per API key, user account, IP address or organization.

When a client goes over the limit, the API rejects further requests until the window resets or capacity frees up. The standard response is HTTP status 429 Too Many Requests, defined in RFC 6585, which says the user “has sent too many requests in a given amount of time.” The server may include a Retry-After header telling the client how long to wait. Retry-After is defined in RFC 9110 and can be either a number of seconds or an HTTP date.

A real example: GitHub’s REST API allows 60 requests per hour for unauthenticated requests (counted by IP) and 5,000 per hour for authenticated users, and it reports usage in headers such as x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset.

If you’re new to APIs in general, start with what an API is.

Why APIs use rate limits

Providers rate limit for 4 main reasons:

1. Protect stability. One runaway script shouldn’t be able to slow down the service for everyone else.
2. Ensure fair use. Shared infrastructure needs each customer to get a fair slice.
3. Security. Limits slow down brute-force login attempts, credential stuffing, scraping and some denial-of-service patterns. OWASP lists “Unrestricted Resource Consumption” as API4 in its 2023 API Security Top 10 and recommends rate limiting, with stricter limits on sensitive endpoints such as password recovery.
4. Business tiers and cost control. Many APIs sell higher limits on paid plans, and limits keep usage-based costs predictable. AI model APIs, for example, often limit both requests and tokens per minute. Our guide to reducing LLM API costs covers that side.

Rate limiting is related to, but different from, quotas (a total allowance per day or month) and throttling (slowing requests down rather than rejecting them). Many APIs use all 3.

The common rate limiting algorithms

Under the hood, rate limiters decide whether each request is allowed. Here are the 5 algorithms you’ll see most often.

Fixed window counter

Count requests in fixed time windows, such as each calendar minute. If the count passes the limit, reject until the next window starts.

• Pros: Very simple and cheap to store (one counter per client per window).
• Cons: Allows bursts at window edges. A client could send the full limit at 12:00:59 and again at 12:01:00, doubling the rate briefly.

Sliding window log

Store a timestamp for every request and count how many fall within the last N seconds.

• Pros: Accurate, no edge bursts.
• Cons: Memory-heavy at high volume, because you keep every timestamp.

Sliding window counter

A hybrid: keep counters for the current and previous fixed windows, and weight the previous window by how much of it overlaps the sliding window.

• Pros: Smooths edge bursts with low memory.
• Cons: An approximation, though usually good enough.

Token bucket

Each client has a bucket that holds up to a maximum number of tokens. Tokens are added at a steady rate. Each request spends a token; if the bucket is empty, the request is rejected.

• Pros: Allows short bursts (up to the bucket size) while enforcing an average rate. Widely used.
• Cons: Needs tuning of 2 numbers, bucket size and refill rate.

Leaky bucket

Requests enter a queue that drains at a fixed rate. If the queue is full, new requests are dropped.

• Pros: Produces a smooth, steady output rate, useful for protecting fragile downstream systems.
• Cons: Bursty traffic gets delayed or dropped rather than served quickly.

Algorithm	Allows bursts?	Accuracy	Memory cost	Typical use
Fixed window	Yes, at window edges	Low to medium	Very low	Simple per-minute or per-day limits
Sliding window log	No	High	High	Low-volume, strict limits
Sliding window counter	Limited	Medium to high	Low	General API limits at scale
Token bucket	Yes, up to bucket size	High	Low	Public APIs, gateways, cloud services
Leaky bucket	No, smooths output	High	Low to medium	Protecting downstream systems

Key takeaway: Many public APIs use token bucket or sliding window variants. As a consumer, you don’t need to know which one a provider uses. You need to read the limit headers, slow down before you hit the wall and retry correctly when you do.

How rate limits are communicated

Good APIs tell you where you stand in response headers. There’s no single universal standard yet:

• Vendor headers such as X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset are common, but names and meanings (seconds until reset versus a Unix timestamp) vary by provider.
• Retry-After is standardized in RFC 9110 and widely sent with 429 and 503 responses.
• IETF RateLimit fields: the IETF HTTPAPI working group is developing standard RateLimit and RateLimit-Policy header fields. As of this writing it is still an Internet-Draft, not a finished RFC, so check the IETF datatracker for its current status.

Always read the specific API’s documentation. Some APIs have multiple limits at once (per second, per hour and per endpoint), plus “secondary” limits on concurrency.

How to handle rate limits as an API consumer

This is where most integrations go wrong. Use these practices to stay inside limits and recover gracefully.

1. Read the limits before you write code

Find the documented limits for your plan and the specific endpoints you use. Note what’s counted (requests, tokens, points), the window and how limits are scoped (per key, per user, per IP).

2. Track the headers on every response

Log remaining requests and reset time. If remaining drops low, slow down proactively instead of waiting for a 429.

3. Respect Retry-After

If a 429 or 503 includes Retry-After, wait at least that long before retrying. It’s the provider telling you exactly what it needs.

4. Retry with exponential backoff and jitter

When no Retry-After is given, wait progressively longer between retries (for example 1, 2, 4, 8 seconds), cap the maximum wait and the number of retries, and add random jitter so many clients don’t retry at the same instant. AWS’s Builders’ Library guidance on timeouts, retries and backoff explains why jitter matters and warns that retries stacked across layers can multiply load dramatically.

attempt = 0 while attempt < max_retries: response = call_api() if response.status != 429 and response.status < 500: return response wait = response.retry_after or min(cap, base * 2 ** attempt) sleep(random_between(0, wait)) # full jitter attempt += 1 raise RateLimitError

5. Only retry safe requests

Retrying a GET is usually safe. Retrying a POST that creates an order or sends a payment can cause duplicates. Use idempotency keys where the API supports them. Don’t retry 4xx errors other than 429 (and sometimes 408) with the same request, because they won’t succeed.

6. Reduce the number of calls

• Cache responses that don’t change often.
• Use bulk or batch endpoints instead of one call per record.
• Use webhooks instead of polling where available. See what a webhook is.
• Request only the fields and pages you need.

7. Throttle on your side

Put a client-side limiter (often a token bucket) in front of your API calls, or use a job queue with controlled concurrency, so your own system never sends faster than the provider allows.

Implementing rate limiting on your own API

If you’re the provider, a few practical pointers:

• Choose the right key. Per API key or per user is fairer than per IP, since many users can share an IP and attackers can rotate them.
• Rate limit at the edge. API gateways, reverse proxies, CDNs and cloud load balancers usually include rate limiting, so you don’t need to build it in application code first.
• Use a shared store such as Redis for counters when you run multiple instances, or limits will apply per server instead of globally.
• Set stricter limits on sensitive endpoints like login, password reset and anything expensive.
• Return clear 429s with Retry-After, limit headers and a helpful error body.
• Document your limits and how to request higher ones.
• Remember resource limits too. OWASP notes that rate limits alone don’t bound the cost of one huge request, so also cap payload sizes, page sizes and execution time.

For the broader design picture, see our guides to designing a REST API and what a DDoS attack is, since rate limiting is one layer of DDoS defense but not a complete one.

Where to start

If you’re consuming an API:

1. Read the rate limit section of the API docs and note every limit that applies to you.
2. Add logging for limit headers and 429 responses.
3. Wrap API calls in a retry helper that respects Retry-After and uses exponential backoff with jitter.
4. Add caching, batching or webhooks to cut unnecessary calls.
5. Load test with realistic data volumes before production.

If you’re building an API, start with gateway-level token bucket limits per API key, stricter limits on auth endpoints, and clear documentation.

Conclusion

API rate limiting keeps shared services stable, fair and secure. Providers use algorithms like token bucket and sliding windows to decide which requests get through, and they signal limits with HTTP 429, Retry-After and rate limit headers. As a consumer, your job is to read those signals, stay under the limits with caching and batching, and retry patiently with backoff and jitter. Do that and a 429 becomes a brief pause rather than an outage. For more definitions, browse our glossary.

Sources

• RFC 6585: Additional HTTP Status Codes — definition of 429 Too Many Requests
• RFC 9110: HTTP Semantics — Retry-After header format
• IETF: RateLimit header fields for HTTP (Internet-Draft) — draft standard RateLimit and RateLimit-Policy fields
• GitHub Docs: Rate limits for the REST API — example limits and x-ratelimit headers
• OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption — rate limiting as a security control
• AWS Builders’ Library: Timeouts, retries and backoff with jitter — exponential backoff, jitter and retry amplification