API Rate Limiting: A Complete Guide for Developers
APIs are the foundation of modern applications. Whether you're building a SaaS platform, mobile application, AI product, or public developer API, your backend can receive thousands or even millions of requests every day.
But what happens when one user sends too many requests?
Without proper controls, excessive API traffic can cause:
- Backend performance problems
- Database overload
- Increased infrastructure costs
- API outages
- Brute-force attacks
- Denial-of-service conditions
- Unfair resource usage between customers
API rate limiting is one of the most effective ways to control API traffic and protect backend infrastructure.
In this guide, we'll explain what API rate limiting is, how it works, common rate limiting algorithms, HTTP 429 responses, different rate limiting strategies, implementation approaches, best practices, and how an edge API gateway can simplify rate limiting.
What Is API Rate Limiting?
API rate limiting is a technique used to control how many requests a client can make to an API within a specific period.
For example, an API might allow:
100 requests per minute per API key
If a client exceeds the limit, the API can temporarily reject additional requests.
A simple flow looks like this:
Client
│
│ Request
▼
API Gateway
│
├── Check rate limit
│
├── Within limit? ─── Yes ──► Backend API
│
└── Limit exceeded? ── No ──► HTTP 429
The purpose isn't necessarily to prevent users from making requests.
Instead, rate limiting ensures that API resources are used within defined boundaries.
Why Is API Rate Limiting Important?
Imagine you have an API endpoint:
POST /api/login
A normal user might make a few requests.
But an attacker could send thousands of requests per second:
Request 1
Request 2
Request 3
...
Request 100,000
If every request reaches your application, your backend has to process all of them.
That can result in:
High traffic
↓
More application processing
↓
More database queries
↓
Higher CPU / memory usage
↓
Slower API responses
↓
Possible outage
With rate limiting:
100,000 requests
↓
Rate Limiter
↓
Allowed requests → Backend
Blocked requests → HTTP 429
The backend receives only the traffic it is designed to handle.
What Problems Does API Rate Limiting Solve?
API rate limiting is useful for several different problems.
1. Preventing API Abuse
Public APIs can be abused by automated scripts, bots, crawlers, or malicious users.
Rate limits make excessive usage more difficult.
2. Protecting Backend Infrastructure
Every API request consumes resources.
Depending on your application, a request may require:
- CPU
- memory
- database queries
- Redis operations
- external API calls
- network bandwidth
Rate limiting helps prevent a sudden increase in traffic from overwhelming these resources.
3. Preventing Brute-Force Attacks
Authentication endpoints are particularly important.
For example:
POST /api/login
Without rate limiting, an attacker could repeatedly attempt passwords.
You could apply a stricter policy:
Login:
5 requests / minute / IP
while allowing a less sensitive endpoint:
Products:
300 requests / minute / IP
4. Controlling Infrastructure Costs
More API requests can mean higher infrastructure costs.
This is especially important when your API calls expensive services such as:
- AI models
- payment providers
- third-party APIs
- database-intensive operations
- serverless functions
Rate limiting can help prevent unexpected traffic from generating unexpected bills.
5. Fair Resource Allocation
Suppose you have 1,000 customers.
Without rate limits, one customer could potentially consume most of your API capacity.
With customer-level limits:
Customer A → 10,000 requests/hour
Customer B → 10,000 requests/hour
Customer C → 10,000 requests/hour
resources can be distributed more predictably.
How Does API Rate Limiting Work?
At its simplest, a rate limiter keeps track of requests associated with a client.
For example:
API Key: abc123
Requests:
10:00:01 → 1
10:00:05 → 2
10:00:12 → 3
10:00:20 → 4
...
The rate limiter compares the request count against a configured limit.
For example:
Limit: 100 requests / minute
Current usage: 73
73 < 100
↓
Request allowed
When the limit is exceeded:
Limit: 100 requests / minute
Current usage: 101
101 > 100
↓
Request rejected
↓
HTTP 429 Too Many Requests
What Is HTTP 429 Too Many Requests?
When a client exceeds an API rate limit, the standard HTTP status code is:
429 Too Many Requests
For example:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 30
The response could contain:
{
"error": "rate_limit_exceeded",
"message": "Too many requests",
"retryAfter": 30
}
The Retry-After header can tell the client how long it should wait before trying again.
This allows well-designed clients to automatically back off instead of continuously retrying.
Common API Rate Limiting Algorithms
There isn't one universal rate limiting algorithm.
Several approaches are commonly used.
The most important ones are:
- Fixed Window
- Sliding Window
- Sliding Window Counter
- Token Bucket
- Leaky Bucket
Let's look at each one.
1. Fixed Window Rate Limiting
The fixed window algorithm divides time into fixed intervals.
For example:
Limit:
100 requests / minute
The system creates windows:
10:00:00 ───────── 10:01:00
10:01:00 ───────── 10:02:00
10:02:00 ───────── 10:03:00
Each window gets its own request counter.
For example:
10:00 window
Requests: 73
73 < 100
Allowed
Once the counter reaches 100:
Requests: 101
101 > 100
Blocked
When the next minute starts, the counter resets.
Advantages
- Simple to implement
- Easy to understand
- Low memory requirements
- Fast
Disadvantages
The biggest problem is the boundary burst.
Imagine:
10:00:59 → 100 requests
10:01:00 → 100 requests
A client could potentially send 200 requests in approximately one second while technically staying within both windows.
This is called the fixed-window boundary problem.
2. Sliding Window Rate Limiting
A sliding window doesn't reset at fixed boundaries.
Instead, it continuously looks backward over a specific period.
For example:
Limit:
100 requests in the last 60 seconds
At 10:01:30, the system checks requests between:
10:00:30 → 10:01:30
At 10:01:31, it checks:
10:00:31 → 10:01:31
The window continuously moves forward.
Advantages
- More accurate than fixed windows
- Reduces boundary bursts
- Better traffic control
Disadvantages
- More complex
- Can require more memory
- Tracking individual timestamps can be expensive at high traffic volumes
3. Sliding Window Counter
A sliding window counter provides a compromise between fixed windows and fully timestamp-based sliding windows.
Instead of storing every request timestamp, the system uses counters from multiple windows and calculates an approximate current usage.
This reduces memory usage while providing smoother rate limiting than a simple fixed window.
It can be useful for high-volume APIs where exact timestamp tracking isn't necessary.
4. Token Bucket Algorithm
The token bucket algorithm is one of the most popular approaches for API rate limiting.
Imagine a bucket that holds tokens.
Each API request consumes one token.
For example:
Bucket capacity: 100 tokens
Refill rate: 10 tokens/second
Initially:
[● ● ● ● ● ● ● ● ● ● ...]
100 tokens
A request consumes a token:
Request
↓
Consume 1 token
↓
99 tokens remaining
Tokens are continuously added back at the configured refill rate.
This means clients can often handle short bursts while still respecting a long-term average rate.
Example
Suppose:
Bucket capacity = 100
Refill rate = 10 tokens/second
A client can make a short burst of requests as long as tokens are available.
Once the bucket is empty:
No tokens
↓
Request rejected
↓
HTTP 429
Advantages
- Supports controlled bursts
- Flexible
- Efficient
- Good for APIs
- Widely applicable
Disadvantages
- Slightly more complex than fixed windows
- Requires careful configuration
5. Leaky Bucket Algorithm
The leaky bucket algorithm processes requests at a controlled rate.
Imagine requests entering a bucket:
Requests
↓ ↓ ↓ ↓ ↓
┌─────────────┐
│ Bucket │
│ │
└──────┬──────┘
│
▼
Controlled
output
Requests are processed at a relatively consistent rate.
If the bucket becomes full, additional requests are rejected or dropped.
This makes the algorithm useful when you want to smooth traffic rather than allow large bursts.
Token Bucket vs Leaky Bucket
The two algorithms are related but behave differently.
| Feature | Token Bucket | Leaky Bucket |
|---|---|---|
| Allows bursts | Yes | Limited |
| Smooths traffic | Moderate | Strong |
| Common API use | Very common | Common |
| Flexible | High | Moderate |
| Request processing | Based on tokens | Based on output rate |
A token bucket is often a good choice when an API needs to support legitimate short bursts.
A leaky bucket is useful when maintaining a more predictable request-processing rate is important.
Rate Limiting Strategies
Choosing the algorithm is only part of the problem.
You also need to decide what should be rate limited.
Rate Limiting by IP Address
The simplest strategy is limiting requests by IP address.
For example:
100 requests/minute/IP
This is useful for public APIs and unauthenticated endpoints.
However, IP-based limits aren't perfect.
Many users can share the same public IP through:
- corporate networks
- universities
- mobile carriers
- VPNs
- NAT gateways
Therefore, an IP address shouldn't always be treated as an individual user.
Rate Limiting by API Key
For developer APIs, API-key-based rate limiting is often more accurate.
For example:
API Key A → 1,000 requests/hour
API Key B → 10,000 requests/hour
API Key C → 100,000 requests/hour
This also makes it easier to create different limits for different subscription plans.
For example:
Free
1,000 requests/month
Pro
100,000 requests/month
Enterprise
10,000,000 requests/month
Rate Limiting by User
Authenticated applications can rate limit based on user identity.
For example:
User ID: 12345
Limit: 500 requests/hour
This can provide better fairness than IP-based rate limiting.
Rate Limiting by Endpoint
Not every API endpoint has the same cost.
For example:
GET /products
500 requests/minute
POST /orders
100 requests/minute
POST /login
10 requests/minute
POST /generate-ai
20 requests/minute
Endpoint-specific limits are often more effective than one global limit.
Rate Limiting by Subscription Plan
SaaS applications frequently implement tier-based rate limits.
For example:
| Plan | Requests/minute | Monthly Requests |
|---|---|---|
| Free | 20 | 10,000 |
| Pro | 200 | 1,000,000 |
| Business | 1,000 | 10,000,000 |
| Enterprise | Custom | Custom |
This makes rate limiting part of the product's usage model.
Global Rate Limits vs Per-User Rate Limits
A robust API often needs multiple layers of rate limiting.
For example:
Global limit:
100,000 requests/minute
+
Per API key:
1,000 requests/minute
+
Per IP:
100 requests/minute
+
Endpoint:
POST /login → 10 requests/minute
This creates multiple protection layers.
If one user starts abusing the API, they can be blocked without necessarily affecting everyone else.
Where Should Rate Limiting Be Implemented?
There are several places where you can implement API rate limiting.
1. Inside the application
For example:
Client
↓
Node.js / NestJS
↓
Rate limiter
↓
Database
Advantages
- Easy to customize
- Full access to application context
- Can use user identity and business rules
Disadvantages
The request has already reached your infrastructure.
If thousands of malicious requests arrive, your application still has to process them before rejecting them.
2. At the Load Balancer
You can implement rate limiting at the load-balancer layer.
Client
↓
Load Balancer
↓
Rate Limit
↓
Application
This moves traffic control earlier in the request path.
3. At the API Gateway
An API gateway is often a natural location for rate limiting.
Client
↓
API Gateway
├── Authentication
├── WAF
├── Rate Limiting
├── Caching
└── Routing
↓
Backend
The advantage is that multiple backend services can share the same rate limiting policies.
4. At the Edge
An edge API gateway can enforce rate limits before requests travel to your origin.
User
↓
Nearest Edge
↓
Rate Limiter
↓
Allowed?
│
├── No → HTTP 429
│
└── Yes
↓
Origin API
This can significantly reduce unnecessary origin traffic.
For APIs with large public traffic volumes, enforcing limits at the edge can be particularly useful.
Distributed Rate Limiting
Rate limiting becomes more complicated when your API runs on multiple servers.
Imagine:
API Gateway
│
┌──────────┼──────────┐
▼ ▼ ▼
Server A Server B Server C
If each server keeps its own counter, you could accidentally allow more requests than intended.
For example:
Limit = 100 requests/minute
Server A → 100
Server B → 100
Server C → 100
Total → 300 requests
The intended limit was 100, but 300 requests were allowed.
This is why distributed rate limiting often requires a shared state system.
Common technologies include:
- Redis
- distributed databases
- edge key-value stores
- centralized rate limiting services
- distributed counters
Rate Limiting With Redis
Redis is frequently used for distributed rate limiting because it provides fast in-memory operations.
A simplified architecture:
API Gateway
│
▼
Rate Limiter
│
▼
Redis
│
▼
Counter
│
┌─────┴─────┐
│ │
Allowed Blocked
│ │
▼ ▼
Backend HTTP 429
A key might look like:
rate_limit:user:12345
or:
rate_limit:ip:203.0.113.10
The counter can expire automatically after the configured time window.
API Rate Limiting Headers
A well-designed API should communicate rate limit information to clients.
Common headers include:
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 27
X-RateLimit-Reset: 1723456789
When the limit is exceeded:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Header naming conventions can vary between APIs, so consistency and clear documentation are more important than a particular custom header name.
How Should API Clients Handle Rate Limits?
A client shouldn't continuously retry immediately after receiving HTTP 429.
Bad behavior:
429
↓
Retry
↓
429
↓
Retry
↓
429
↓
Retry
This can make the situation worse.
Instead, clients should use backoff.
For example:
Request
↓
429
↓
Wait
↓
Retry
↓
429
↓
Wait longer
↓
Retry
A common strategy is exponential backoff with jitter.
For example:
1 second
2 seconds
4 seconds
8 seconds
16 seconds
Random jitter can be added so that many clients don't retry simultaneously.
API Rate Limiting Best Practices
1. Don't use one limit for everything
Different endpoints have different costs.
A database-heavy endpoint should usually have a different limit from a lightweight endpoint.
2. Return HTTP 429
Use the standard:
429 Too Many Requests
when the client exceeds the configured request rate.
3. Tell clients when to retry
Use Retry-After where appropriate.
This makes your API easier to consume.
4. Document your limits
Developers should know:
- request limits
- time windows
- quota rules
- burst behavior
- response headers
- retry behavior
Poorly documented rate limits can lead to frustrating API integrations.
5. Use multiple rate limiting dimensions
Depending on your API, consider combining:
IP
API Key
User
Endpoint
Organization
Subscription Plan
6. Protect expensive endpoints more aggressively
For example:
GET /health
→ 1,000 req/min
GET /products
→ 500 req/min
POST /generate
→ 20 req/min
The limits should reflect the actual resource cost.
7. Don't rely only on IP addresses
IP addresses can represent many users.
For authenticated APIs, API keys, user IDs, or organization IDs often provide more meaningful rate limiting identities.
8. Monitor rate-limit events
Track:
- requests blocked
- top rate-limited clients
- rate-limit frequency
- affected endpoints
- geographic traffic
- sudden traffic spikes
This can help distinguish legitimate growth from abuse.
9. Combine rate limiting with other security controls
Rate limiting isn't a complete security solution.
For public APIs, consider combining:
DDoS protection
+
WAF
+
Authentication
+
Rate limiting
+
Bot detection
+
Monitoring
Rate Limiting vs Throttling
The terms rate limiting and throttling are sometimes used interchangeably, but they can describe slightly different behaviors.
Rate limiting
Sets a maximum number of requests that can be accepted during a period.
100 requests/minute
Throttling
Can refer more broadly to controlling or slowing traffic when a threshold is reached.
For example:
Normal traffic
↓
High traffic
↓
Slow processing
↓
Extreme traffic
↓
Reject requests
The exact terminology depends on the API platform.
Rate Limiting vs Quotas
Rate limits and quotas solve different problems.
Rate limit
Controls how quickly requests can be made.
100 requests/minute
Quota
Controls how many requests can be consumed over a longer period.
1,000,000 requests/month
You can use both:
Per minute:
1,000 requests
Per month:
10 million requests
This is common in SaaS and developer API pricing.
Rate Limiting for AI APIs
Rate limiting is particularly important for AI applications.
An AI request may consume significantly more resources than a normal API request.
For example:
GET /products
→ inexpensive
POST /generate
→ model inference
→ expensive
An AI platform might therefore use several limits:
Requests/minute
Tokens/minute
Tokens/day
Requests/day
Monthly usage
For example:
Free:
10 requests/minute
100,000 tokens/month
Pro:
100 requests/minute
5,000,000 tokens/month
AI APIs often need both request-based limits and usage-based quotas.
Rate Limiting for Webhooks
Webhooks can also benefit from rate limiting.
Imagine a third-party service sends:
10,000 webhook events
within a few seconds.
Your webhook endpoint may become overloaded.
A gateway can help control the traffic before it reaches your application:
Webhook Provider
│
▼
API Gateway
│
├── Rate Limit
├── WAF
├── Validation
└── Queue / Routing
│
▼
Webhook Service
This is particularly useful for SaaS platforms that receive high-volume events.
How EdgeWrap Can Help With API Rate Limiting
Managing rate limiting independently in every backend service can become difficult as your infrastructure grows.
EdgeWrap provides an edge API gateway layer that can sit in front of your existing APIs.
Instead of implementing traffic controls independently across multiple services:
Client
│
├────► User API
│
├────► Order API
│
└────► Payment API
you can put a gateway in front:
Client
│
▼
┌───────────┐
│ EdgeWrap │
│ │
│ WAF │
│ Rate Limit│
│ Cache │
│ Routing │
└─────┬─────┘
│
┌───────────┼───────────┐
▼ ▼ ▼
User API Order API Payment API
This allows rate limiting and other API policies to be managed at a centralized layer.
You can configure your gateway through the EdgeWrap dashboard and use the EdgeWrap documentation for configuration and implementation details.
Example API Rate Limiting Architecture
A production API might use multiple controls:
Internet
│
▼
┌───────────────┐
│ EdgeWrap │
│ │
│ DDoS │
│ WAF │
│ Bot Detection │
│ │
│ Rate Limiting │
│ │
│ Cache │
│ │
│ Analytics │
└───────┬───────┘
│
▼
┌─────────────┐
│ API Gateway │
└──────┬──────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Service A Service B Service C
│ │ │
└─────────────┼─────────────┘
▼
Database
The important architectural principle is to reject unnecessary traffic as early as possible.
If a request can be safely rejected at the edge, there's little reason to send it through your application servers and database.
How to Choose the Right Rate Limit
There is no universal value such as:
100 requests/minute
that works for every API.
Instead, consider:
1. Endpoint cost
How expensive is the request?
2. Backend capacity
How many requests can your infrastructure safely process?
3. User behavior
How frequently do legitimate users make requests?
4. Traffic patterns
Do users naturally send bursts?
5. Subscription plan
Should different customers have different limits?
6. Abuse potential
Could the endpoint be targeted by attackers?
For example:
Suggested Policy
Health Check → High limit
Product Listing → Medium/High
Search → Medium
Login → Low
Password Reset → Very Low
AI Generation → Low + Token Quota
Payment → Low + Authentication
The best rate limit is based on your application's actual behavior and capacity.
Common API Rate Limiting Mistakes
Mistake 1: Setting limits too low
If legitimate clients frequently receive HTTP 429 responses, your API becomes difficult to use.
Mistake 2: Setting limits too high
A limit that doesn't meaningfully protect your infrastructure isn't useful.
Mistake 3: Rate limiting only after the request reaches the application
This still consumes backend resources.
For high-risk public APIs, earlier enforcement can be more effective.
Mistake 4: Using only IP-based limits
Shared networks can cause legitimate users to affect each other.
Mistake 5: Not telling clients about limits
Developers need to know how to handle HTTP 429 responses.
Mistake 6: Ignoring distributed infrastructure
Per-server counters can produce incorrect global limits when traffic is distributed across multiple servers.
Mistake 7: No monitoring
You need visibility into why requests are being blocked.
Otherwise, it's difficult to distinguish abuse from legitimate traffic growth.
API Rate Limiting Checklist
Before deploying an API, consider this checklist:
☐ Define limits per endpoint
☐ Choose a rate limiting algorithm
☐ Decide what identifies a client
☐ Configure burst behavior
☐ Return HTTP 429
☐ Consider Retry-After
☐ Document limits
☐ Monitor rate-limit events
☐ Protect authentication endpoints
☐ Protect expensive operations
☐ Consider distributed rate limiting
☐ Combine rate limiting with WAF/DDoS protection
☐ Review limits as traffic grows
Frequently Asked Questions
What is API rate limiting?
API rate limiting controls how many requests a client can make to an API during a specific period. It helps prevent abuse, protect backend infrastructure, control costs, and ensure fair resource usage.
What happens when an API rate limit is exceeded?
The API typically returns the HTTP 429 Too Many Requests status code. The response may also include a Retry-After header indicating when the client should try again.
What is the best API rate limiting algorithm?
There is no single best algorithm. Fixed windows are simple, sliding windows provide smoother control, and token buckets are useful when you need to support controlled bursts.
Should API rate limiting be based on IP or API key?
It depends on your application. IP-based limits work well for unauthenticated traffic, while API-key or user-based limits are often more appropriate for authenticated developer APIs.
Can API rate limiting prevent DDoS attacks?
Rate limiting can help reduce abusive traffic, but it should not be considered a complete DDoS protection solution. Large-scale DDoS attacks generally require dedicated edge-level mitigation.
Can rate limiting reduce API costs?
Yes. By preventing excessive requests from reaching your backend or expensive third-party services, rate limiting can help control infrastructure and API usage costs.
What is the difference between rate limiting and quotas?
Rate limiting controls the speed of requests, such as 100 requests per minute. A quota controls total usage over a longer period, such as 1 million requests per month.
Where should API rate limiting be implemented?
Rate limiting can be implemented inside your application, at a load balancer, API gateway, or edge layer. For protecting origin infrastructure, enforcing limits closer to the edge can prevent unnecessary requests from reaching your backend.
Final Thoughts
API rate limiting is a fundamental part of building reliable and secure APIs.
A good rate limiting strategy helps you:
- Protect backend infrastructure
- Prevent API abuse
- Reduce unnecessary traffic
- Control infrastructure costs
- Protect expensive endpoints
- Provide fair access to resources
- Improve API reliability
- Handle traffic spikes
The most effective implementations usually combine several controls:
API Protection
│
┌───────────────┼────────────────┐
▼ ▼ ▼
Authentication Rate Limiting WAF
│ │ │
└───────────────┼────────────────┘
▼
DDoS Protection
│
▼
Caching
│
▼
Backend
As your API grows, implementing rate limiting directly inside every service can become difficult to maintain. A centralized API gateway can move these concerns into a dedicated infrastructure layer.
If you want to manage API traffic at the edge, EdgeWrap provides a managed API gateway with rate limiting alongside security, caching, routing, reliability, and API observability features. You can learn more about configuring it in the EdgeWrap documentation.
Top comments (0)