Note: This is a part of our API Security series where we solve common developer queries in detail with how-to guides, common examples, code snippets and a ready to use security checklist. Feel free to check other articles on topics such as authentication methods, rate limiting, API monitoring and more.
Every API has limits - and hitting them is one of the most common and disruptive problems developers encounter when building integrations at scale. Rate limiting controls how many requests a client can make in a given time window. Throttling slows requests down instead of blocking them outright. Together, they're the mechanisms that keep APIs stable under load - and the ones your integration code needs to handle gracefully.
This guide covers 10 implementation best practices developers need in 2026: choosing the right algorithm, handling 429 errors correctly, implementing exponential backoff, and how tools like Knit abstract rate limit handling automatically across 50+ third-party APIs.
What is API Rate Limiting
API rate limiting is a technique that restricts how many requests a client can make to an API within a defined time window - for example, 100 requests per minute per API key. When a client exceeds the limit, the API returns an HTTP 429 Too Many Requests error. Rate limiting protects API infrastructure from abuse, ensures fair usage across clients, and prevents any single integration from degrading performance for others. Most third-party APIs - including Workday, ADP, Salesforce, and QuickBooks - enforce rate limits that developers must handle explicitly in their integration code.
With rate limiting, you define the maximum number of requests a client can make to your API within a specified time window, such as requests per second or requests per minute.
If a client exceeds this limit, they are temporarily blocked from making additional requests, ensuring that your API's resources are not overwhelmed.
What is API Throttling
Throttling is like controlling the flow of traffic at a toll booth. Instead of completely blocking a client when they exceed the rate limit, throttling slows down their requests, spreading them out more evenly over time.
This helps prevent abrupt spikes in traffic and maintains a steady, manageable flow.
Benefits of Rate Limiting
Now, let's talk about why rate limiting is so crucial in the realm of API security.
1. Preventing abuse
Rate limiting acts as a shield against abuse and malicious attacks. It prevents one client from bombarding your API with a barrage of requests, which could lead to system overload or denial-of-service (DoS) attacks.
2. Ensuring fair usage
Rate limiting ensures fair access for all clients, regardless of their size or importance. It prevents a single client from monopolizing your API's resources, allowing everyone to enjoy a smooth and equitable experience.
3. Improved reliability
By maintaining control over the rate of incoming requests, you can ensure the reliability and availability of your API. This is especially critical when dealing with limited resources or shared infrastructure.
4. Security
Rate limiting can also be an effective tool in identifying and mitigating potential API security threats. It helps you spot unusual patterns of behavior, such as repeated failed login attempts, which could indicate a brute-force attack.
How to implement rate limiting and throttling
1. Define your rate limiting strategy
There are two steps here -
- Set rate limits: Determine how many requests a client can make within a specific time window (e.g., requests per second, minute, or hour). This limit should align with your API's capacity and the needs of your users.
- Choose the time window: Decide on the time window during which the rate limits apply. Common choices include per second, per minute, or per hour.
2. Identify clients
Ensure that clients are properly authenticated, so you can track their usage individually. OAuth tokens, API keys, or user accounts are commonly used for client identification.
Read: Top 5 API Authentication Methods
3. Implement rate limiting logic
- In-memory or external store: Choose whether to store rate-limiting data in-memory (suitable for smaller-scale applications) or use an external data store like Redis or a database for scalability.
- Track request count: For each client, keep track of the number of requests made within the current time window.
- Check request count: Before processing each incoming request, check if the client has exceeded their rate limit for the current time window.
4. Handle rate limit exceedances
If a client exceeds their rate limit, you have several options:
- Reject the request with a 429 Too Many Requests HTTP response,
- Delay the request (throttling), or
- Implement a queuing system to process requests when the rate limit resets.
5. Reset rate limits
Ensure that rate limits reset at the end of the defined time window. Clients should regain access to the API once the time window expires.
6. Logging and monitoring
Implement comprehensive logging to keep track of rate-limiting events and identify potential abuse or anomalies and set up monitoring tools and alerts to detect unusual patterns or rate-limit exceedances in real-time.
7. Inform clients
Include rate-limiting information in the HTTP response headers, such as "X-RateLimit-Limit," "X-RateLimit-Remaining," and "X-RateLimit-Reset," so clients can be aware of their rate limits.
8. Test and iterate
Thoroughly test your rate-limiting implementation to ensure it works as expected without false positives or negatives and monitor the effectiveness of your rate-limiting strategy and adjust it as needed based on actual usage patterns and evolving requirements.
9. Consider rate limiting algorithms
There are two options here -
- Token bucket algorithm: This is a common rate limiting algorithm where tokens are added to a bucket at a fixed rate. Clients can only make requests if they have tokens in their bucket.
- Leaky bucket algorithm: In this algorithm, requests are processed at a fixed rate. Excess requests are stored in a "leaky bucket" and processed when there's capacity.
10. Implement API throttling (Optional)
If you choose to implement throttling, slow down requests for clients who exceed their rate limits rather than blocking them entirely. This can be achieved by delaying request processing or using a queue system.
Stop being rate limited
Unified APIs like Knit can absolve your rate limiting problem by making sure data sync happens smoothly even during bulk transfer.
For example, Knit has a couple of preventive mechanisms in place to handle rate limits of for all the supported apps.
- Knit has retry, delay mechanisms, and other resiliency measures to make sure no information is missed.
- We make sure that we space out the API calls so that we don't hit the app rate limit, or concurrency limit.
- And in case a rate limit has been hit, Knit immediately responds to 429 error code absolving you of the burden to solve the rate limiting issue on your end. It immediately implements the retry mechanisms that would intercept the failed request, and retry it when the rate limit allows.
These retry and delay mechanisms ensure that you don't miss out on any data or API calls because of rate limits. This becomes essential when we handle data at scale. For example, while fetching millions of applications in ATS or thousands of employees in HRIS.
Along with rate limits, Knit has other data safety measures in place that lets you sync and transfer data securely and efficiently, while giving you access to 50+ integrated apps with just a single API key. Thus, helping you scale your integration strategy 10X faster.
Learn more or get your API keys for a free trial
Frequently Asked Questions
What is API rate limiting?
API rate limiting is a mechanism that restricts how many requests a client can make to an API within a defined time window — for example, 100 requests per minute per API key. When a client exceeds the limit, the server returns an HTTP 429 Too Many Requests response. Rate limiting protects API infrastructure from abuse, ensures fair usage across all clients, and prevents any single consumer from degrading performance for others. Most third-party APIs — including Workday, Salesforce, GitHub, and QuickBooks — enforce rate limits that developers need to handle explicitly in their integration code.
What is the difference between rate limiting and throttling?
Rate limiting sets a hard cap on request volume within a time window - requests above the limit are rejected with a 429 error. Throttling is softer: instead of rejecting requests outright, it slows them down by introducing delays, queuing excess requests, or deprioritizing them behind lower-volume traffic. Rate limiting is generally better suited for programmatic API access where clients are expected to implement backoff logic. Throttling is better for user-facing endpoints where a hard failure would degrade the experience - slowing a response down is preferable to returning an error.
How would you handle rate limiting in an API?
The standard pattern for handling rate limits as an API consumer: catch 429 responses, read the Retry-After header for the exact wait time, implement exponential backoff with jitter if no header is present, and queue non-urgent requests rather than retrying immediately. Use idempotency keys on retried requests to avoid duplicate writes. For APIs you control, return clear rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) and document your limits explicitly — it significantly reduces support burden. Tools like Knit handle this automatically when consuming third-party APIs like Workday, ADP, or Salesforce, abstracting per-provider retry logic so application code stays clean.
What is a good API rate limit?
There's no universal number - the right rate limit depends on your infrastructure capacity, the cost of each request, and your client mix. Common starting points for production REST APIs: 60–300 requests per minute for general endpoints, 10–30 RPM for expensive write or search operations, and 1,000–5,000 RPM for lightweight read endpoints with caching. Enterprise APIs like Salesforce typically allow 100,000 API calls per 24 hours per org; GitHub allows 5,000 requests per hour per authenticated token. Whatever limits you set, expose them via response headers and version your limits clearly in documentation so clients can plan around them.
How do you handle 429 Too Many Requests errors?
On receiving a 429:
(1) check the Retry-After header - it tells you exactly how many seconds to wait before retrying;
(2) if there's no Retry-After header, use exponential backoff starting at 1–2 seconds, doubling each attempt with added random jitter;
(3) cap retries at 3–5 attempts and surface a proper error if all fail - never drop the request silently;
(4) if 429s are happening frequently, the real fix is upstream: audit your request volume, implement a queue, or reduce polling frequency.
Knit handles 429 retry logic automatically for all third-party integrations it supports, so developers building on top of HR, payroll, or CRM APIs don't need to implement this per provider.
How long does a 429 Too Many Requests error last?
It depends on the API's rate limit window - most use fixed windows of 1 minute, 15 minutes, or 1 hour. The Retry-After response header will give you the exact duration in seconds. Once the window resets, your request quota refreshes and calls will succeed again. Some APIs use sliding windows instead of fixed ones, which means the reset time shifts with each request rather than resetting at a fixed interval. If you're seeing persistent 429s that last much longer than expected, check whether the provider has implemented temporary bans for clients that retry too aggressively - some APIs (including OpenAI) will extend the backoff period if they detect rapid retry loops.
What are the best algorithms for API rate limiting?
The four most commonly used algorithms are:
Fixed Window — simplest to implement, counts requests in a fixed period but allows burst spikes at window boundaries;
Sliding Window — smoother than fixed window, tracks a rolling time period to prevent boundary bursts;
Token Bucket — allows controlled bursts by accumulating tokens up to a cap, with each request consuming one token; best for APIs that want to tolerate natural traffic variation.
Leaky Bucket — processes requests at a fixed constant rate regardless of incoming volume, smoothing traffic completely but rejecting all bursts.
Token bucket is the most widely used for REST APIs because it handles bursty-but-bounded traffic patterns without penalizing clients for low activity periods.
.webp)
