What is API Rate Limiting? Understanding Request Throttling and Best Practices

If you’ve ever seen a 429 Too Many Requests error, you’ve encountered rate limiting in action. API rate limiting, also known as request throttling, controls the number of requests a client can make within a specified time window. It protects backend systems from overload while ensuring fair access for all consumers.

This guide explains what rate limiting is, why it matters, the most common algorithms you can use, and how to test rate limits in Postman.

What is API rate limiting?

API rate limiting restricts the number of requests a client can make to an API within a specific time window. When a client exceeds the allowed threshold, the API rejects additional requests and typically returns a 429 Too Many Requests response.

Think of it like a highway toll booth. Traffic flows smoothly at a steady rate, but if too many cars try to enter at once, the system slows or stops new arrivals to prevent congestion. Rate limiting applies the same principle to API traffic.

Rate limiting serves several critical functions:

• Prevents abuse by stopping malicious actors from overwhelming your API.

• Ensures reasonable access for all users.

• Manages infrastructure expenses by limiting unnecessary traffic.

• Keeps response times fast during high-traffic periods.

• Defends against DDoS, credential stuffing, and brute-force attacks.

Why API rate limiting is essential

Preventing abuse and security threats

Without rate limiting, malicious users can flood your API with requests, making it unavailable for legitimate users. Rate limiting acts as a first line of defense by automatically rejecting excessive traffic.

Common threats mitigated by rate limiting include:

• DDoS attacks: attempts to crash your servers with overwhelming traffic.

• Credential stuffing: automated login attempts using leaked credentials.

• Brute force attacks: repeated attempts to guess passwords or API keys.

• Web scraping: unauthorized data harvesting that consumes resources.

Managing server resources

Every API request consumes CPU, memory, bandwidth, and often database connections. Rate limiting prevents a single client from exhausting these shared resources.

For example, if an API can handle 10,000 requests per minute, you might limit individual users to 100 requests per minute. This prevents a single misconfigured script from consuming all available capacity.

Controlling costs

Many cloud platforms and third-party APIs charge based on request volume. Rate limiting helps control operational costs by capping unnecessary or abusive traffic, especially when each request triggers downstream paid services.

How API rate limiting works

At a high level, rate limiting follows a simple flow:

1. A client sends a request to the API.

2. The rate limiter checks the number of requests that client has made recently.

3. The request count is compared to the configured limit.

4. The request is accepted or rejected.

5. Response headers communicate the current rate limit status.

Rate limit response headers

APIs often include headers that help clients understand their current usage:

HTTP/1.1 200 OK
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 847
X-RateLimit-Reset: 1677721600

These headers tell clients:

• X-RateLimit-Limit: total requests allowed in the time window

• X-RateLimit-Remaining: requests left in the current window

• X-RateLimit-Reset: when the limit resets

Rate limit exceeded response

When a client exceeds the limit, the API typically responds with a 429 status:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
X-RateLimit-Remaining: 0

{
  "error": "Rate limit exceeded",
  "message": "Try again in 60 seconds"
}

The Retry-After header tells the client how long to wait before sending another request.

Types of rate limiting algorithms

Different algorithms offer different trade-offs between flexibility and accuracy.

Token bucket algorithm

Allows short bursts while enforcing an average rate.

How it works:

• Tokens are added to a bucket at a fixed rate, such as 10 tokens per second.

• The bucket has a maximum capacity, such as 100 tokens.

• Each request consumes one token.

• Requests are rejected when no tokens remain.

Best for: APIs that need to allow occasional traffic spikes without sustained overload.

Leaky bucket algorithm

Processes requests at a constant rate, regardless of arrival speed. Requests queue in the bucket and “leak” out at a fixed rate.

How it works:

• Incoming requests are placed into a queue.

• Requests are processed at a steady rate.

• When the queue is full, new requests are rejected.

Best for: APIs that require smooth, predictable load on backend systems.

Fixed window algorithm

Divides time into fixed intervals with a request limit per window.

How it works:

• Time is divided into fixed windows, such as one minute.

• Each window allows a fixed number of requests, such as 100.

• Counters reset at the start of each window.

Best for: Simple implementations where occasional boundary spikes are acceptable.

Sliding window algorithm

Tracks requests within a moving time window, providing more accurate limiting than fixed windows.

How it works:

• Maintains a rolling time window, such as the last 60 seconds.

• Counts only requests within that window.

• Updates continuously rather than resetting abruptly.

Best for: Production APIs that require precise, fair rate limiting.

Implementing API rate limiting step by step

Step 1: Choose your algorithm

Choose an algorithm based on your traffic patterns. For most production APIs, sliding window offers the best balance of accuracy and fairness.

Step 2: Define your limits

Set limits based on:

• Server capacity and typical load

• Expected legitimate usage patterns

• Business tiers or pricing models

• Downstream service costs

It’s usually best to start conservatively and adjust based on real usage data.

Step 3: Expose rate limit headers

Include rate limit information in responses:

response.setHeader('X-RateLimit-Limit', '1000');
response.setHeader('X-RateLimit-Remaining', remaining);
response.setHeader('X-RateLimit-Reset', resetTime);

Step 4: Handle exceeded limits

Return clear 429 responses with actionable guidance:

{
  "error": "Rate limit exceeded",
  "message": "Maximum 1000 requests per hour. Try again in 45 minutes.",
  "retry_after": 2700
}

Step 5: Document your limits

Your API documentation should clearly explain:

• Request limits and time windows

• How clients are identified

• Response codes and headers

• Recommended retry behavior

Testing rate limits in Postman

Basic rate limit testing

1. Create a new collection.

2. Add a request to your API endpoint.

3. Add a test script:

pm.test("Rate limit headers present", function () {
    pm.expect(pm.response.headers.has('X-RateLimit-Limit')).to.be.true;
    pm.expect(pm.response.headers.has('X-RateLimit-Remaining')).to.be.true;
});

pm.test("Track remaining requests", function () {
    const remaining = pm.response.headers.get('X-RateLimit-Remaining');
    console.log(`Remaining: ${remaining}`);
});

4. Use the Collection Runner to send multiple rapid requests.

5. Confirm that the API returns a 429 response when the limits are exceeded.

Testing 429 responses

pm.test("Returns 429 when limit exceeded", function () {
    pm.response.to.have.status(429);
});

pm.test("Includes Retry-After header", function () {
    pm.expect(pm.response.headers.has('Retry-After')).to.be.true;
});

Best practices for API rate limiting

Start conservative, then optimize

Begin with stricter limits than necessary, then gradually relax based on real usage patterns. It’s easier to increase limits than impose new restrictions.

Communicate clearly

Make limits easy to understand by documenting:

• Exact thresholds per tier

• Time windows

• How to interpret headers

• How to request limit increases

Implement tiered limits

Different users have different needs:

• Free tier: 100 requests per hour

• Basic tier: 1,000 requests per hour

• Pro tier: 10,000 requests per hour

• Enterprise: Custom limits

Monitor and adjust

Track metrics like:

• Rate limit hit frequency

• Request volume distribution

• Patterns in violations

• Impact on performance

Use exponential backoff

Guide clients to retry with increasing delays:

let delay = 1000; // Start with 1 second

for (let attempt = 0; attempt < maxRetries; attempt++) {
  try {
    return await makeRequest();
  } catch (error) {
    if (error.status === 429) {
      await sleep(delay);
      delay *= 2; // Double delay each attempt
    }
  }
}

Common rate-limiting challenges

Balancing security with usability

Limits that are too strict frustrate legitimate users. Limits that are too loose invite abuse. You can strike a balance by:

• Studying real usage patterns

• Monitoring false positives

• Allowing short bursts

• Offering upgrade paths

Handling distributed systems

In distributed architectures, enforcing accurate global limits is harder. Common approaches include:

• Centralized counters using systems like Redis

• Per-node limits that approximate a global cap

• Accepting minor inaccuracies in exchange for performance

Rate limiting in practice

E-commerce APIs

E-commerce platforms typically implement tiered limits based on operation type:

Product browsing (GET): 100 requests per minute
Cart operations (POST): 50 requests per minute
Checkout processing (POST): 10 requests per minute

Write operations, such as checkout, have stricter limits because they’re more resource-intensive and require database writes.

Social media platforms

Social platforms often use multiple time windows for different actions:

Reading posts: 180 requests per 15 minutes
Creating posts: 300 requests per 3 hours
Search queries: 450 requests per 15 minutes

This approach prevents spam while allowing legitimate engagement.

Payment processing

Payment APIs implement very strict limits on transaction endpoints:

Payment creation: 10 requests per minute
Refund processing: 5 requests per minute
Balance inquiries: 100 requests per minute

Financial operations require careful rate limiting to prevent fraud and ensure transaction integrity.

Authentication endpoints

Login and authentication endpoints typically have the strictest limits:

Login attempts: 5 requests per 15 minutes
Password reset: 3 requests per hour
Token refresh: 20 requests per hour

This protects against credential stuffing and brute-force attacks while allowing legitimate authentication flows.

Final thoughts

API rate limiting protects your infrastructure while providing reliable service to legitimate users. By choosing the right algorithm, setting realistic limits, and communicating clearly with consumers, you can keep your APIs fast, secure, and dependable under any load.