API Rate Limiting for More Reliable Workflows

A workflow that works for 10 records won’t necessarily work for 10,000. The more API calls you make, the more often that API will tell you to slow down.

That’s API rate limiting in a nutshell: Services cap requests over a given period to manage traffic and protect their infrastructure.

But hitting a limit doesn’t have to mean a failed run. With the right approach, you can work within API rate limits without derailing the workflow. This guide shows you how.

What’s an API rate limit and how does it work?

An API rate limit sets a cap on how many requests a client can make within a certain period. One API might allow 100 requests per minute while another uses a daily quota or limits requests based on the endpoint you’re calling.

These limits help APIs manage traffic without letting one client consume more than its share of resources. How they do that varies. Some APIs allow short bursts of activity; others aim for a steadier flow of requests.

Common rate-limiting algorithms

Most rate limits are built around a few common algorithms:

• Token bucket: Requests use tokens from a bucket that refills over time. If you’ve saved up enough tokens, you can send a burst of requests without immediately hitting the limit.
• Leaky bucket: Requests enter a queue and get processed at a steady rate, which smooths out sudden spikes instead of allowing bursts through all at once.
• Fixed window: Requests are counted during a set interval, like 100 requests between 2:00 and 2:01 p.m. The counter resets when the next window begins.
• Sliding window: Instead of resetting at a fixed boundary, the API looks back over a rolling period to avoid the traffic spikes that can happen around a fixed-window reset.

Rate limit response headers and the 429 contract

You don’t usually need to know which algorithm an API uses to work with its limits. What matters is how the API tells you where you stand.

Some APIs return headers that show your request allowance or when a limit resets. If you exceed the limit, the standard response is 429 Too Many Requests. A Retry-After header may also tell you how long to wait before trying again.

For an automated workflow, those signals are useful instructions. Instead of treating every 429 as an unexpected failure, you can use the information the API provides to decide when it’s safe to continue.

How to choose an API rate-limiting algorithm

If you’re building an API limiter yourself, there isn’t one “best” algorithm. The right choice depends on the traffic you expect and how much a sudden burst of requests matters to the service behind your API.

The trade-offs become clearer when you compare the common approaches side by side.

Token bucket vs. leaky bucket

Both algorithms control request volume, but they handle bursts differently.

A token bucket builds up capacity over time. If there are enough tokens available, a client can spend several at once, making it a good fit when short bursts are acceptable. A leaky bucket takes the opposite approach. It processes requests at a steady rate, smoothing out spikes before they reach the service.

So the choice comes down to how much variation your system can tolerate. Token buckets leave room for bursts, while leaky buckets favor a more predictable request rate.

Fixed window vs. sliding window

A fixed window is straightforward: Count requests during a set period, then reset the counter. The catch is what happens around that reset. A client could use its full allowance at the end of one window and again at the start of the next, creating a sudden spike.

A sliding window avoids that hard reset by measuring requests over a continuously moving period. That gives you a more accurate picture of recent traffic, but it also takes more work to track.

If simplicity matters most, a fixed window may be enough. If you need tighter control over request volume, a sliding window is usually the better fit.

API rate-limiting best practices at scale

Picking an algorithm is only part of the job. As an API grows, the same limit rarely makes sense for every client or endpoint. You also need to make those limits easy to understand and keep an eye on whether they’re still doing what you intended.

Set limits based on clients and endpoints

A request that triggers a complex database query costs more than one that fetches a cached response. Likewise, a paid customer may need more capacity than someone testing a free plan.

Tiered limits let you account for those differences instead of putting every request under the same ceiling. You can set different thresholds by endpoint, client, or plan based on the resources they consume and the traffic you expect.

Make your limits clear

A rate limit shouldn’t come as a surprise. Document what the limits are and return useful information when clients get close to (or exceed) them.

Response headers can tell clients how much capacity they have left or when a limit resets. If you return a 429 Too Many Requests response, include a Retry-After header when possible so clients know when to try again.

Revisit limits as traffic changes

The limit that works today may not make sense six months from now. Traffic patterns change, infrastructure scales, and some endpoints become more expensive as the product evolves.

Monitor how often clients hit their limits and whether bursts are putting pressure on the systems behind your API. That gives you real usage data to work from when it’s time to adjust the thresholds.

Building workflows that respect API rate limits

When you’re calling someone else’s API, you don’t get to choose the rate limit. You do get to choose what your automation does when it hits one.

In n8n, you can build that behavior into the workflow itself. n8n is a source-available, AI-native workflow automation platform, where engineering teams create AI agents and agentic systems. Instead of letting a burst of requests end in failed executions, you can control how quickly requests go out and what happens when the API tells you to wait. 

Respect Retry-After instead of retrying immediately

If an API returns a 429, firing off the same request again right away usually makes things worse. Check the response headers first. When the API provides Retry-After, use it to determine how long the workflow should wait before trying again.

n8n gives you a few ways to handle API rate limits without rebuilding the retry logic from scratch. For simpler cases, Retry On Fail lets you retry a failed node after a configurable wait. You can also use Loop Over Items and Wait nodes when you need more control over when the next request goes out.

If the API keeps rejecting requests after your retry policy is exhausted, an error workflow gives you somewhere to handle the failure instead of letting it disappear into a long execution log.

Slow down before you hit the limit

You don’t have to wait for a 429 to start pacing requests. If an API publishes its limits, build around them from the start.

HTTP Request integrations let you call REST APIs , including services that don’t have a dedicated n8n node. When you know an API can only accept requests at a certain rate, the HTTP Request node can split items into batches and add a delay between them. This way you’re controlling the request rate up front instead of waiting for the API to slow you down.

Reduce the number of external API requests

In certain cases, you can avoid hitting API rate limits simply by reducing the number or outgoing requests. There are two main ways to do this:

1. Prefetch data instead of retrieving items one by one. Many API services allow you to get a single item or a filtered array of items. At the beginning of your workflow, retrieve an array with a single HTTP request and then iterate through it.
2. If the external API stores static data, you can “cache” it locally using data tables. For example, a cloud-based CRM might contain a list of users with their email addresses. You don’t need to request this list via the API every time you want to send an email or to the appropriate person. You can simply store this data in a data table to reduce the number of requests. Don’t forget to update the data table when the external source changes (i.e. include a sync step in the automation that adds or removes the users).

Protecting your own webhook-triggered workflows

There’s an important distinction when the traffic is coming into n8n. A Webhook node can expose a workflow to external requests, but n8n isn’t an API gateway and doesn’t provide built-in inbound rate limiting.

For a public webhook that could receive heavy or unpredictable traffic, put a dedicated API gateway or web application firewall (WAF) in front of n8n. That layer can enforce request limits before the traffic reaches your workflow.

When you need a gateway in front of n8n

For self-hosted n8n deployments handling lots of executions, queue mode lets workers process executions independently. Concurrency controls can also limit how many production executions run at once.

Those features protect execution capacity, but they solve a different problem from API rate limiting. They don’t stop a third-party API from throttling your requests, and they don’t turn n8n into an inbound rate limiter. You’ll still need to pace outgoing requests and use a gateway for incoming heavy traffic.

Build around API rate limits, not against them

API rate limiting is a two-sided problem. API providers need to control traffic, while the workflows calling those APIs need to respect the limits they set. Understanding both sides helps you build automations that can keep running as request volume grows.

n8n can’t stop a third-party API from throttling you. But with retry and batching behavior built into your workflow, a 429 can become a pause instead of a broken run.