API Rate Limits in Make: Fixing 429 Errors in Pipelines

That design ignores the difference between a temporary quota boundary, a malformed request, an unavailable service, and an internal Make limit. The scenario may appear resilient in a diagram, yet remain architecturally incapable of distinguishing recoverable pressure from a permanent failure.

HTTP 429, or Too Many Requests, is not an application error in the usual sense. It is a pacing signal. A remote API, or occasionally Make itself, is telling the pipeline that its current request velocity exceeds an allowed quota. The correct response is not blind repetition. It is controlled delay, bounded retrying, and enough observability to identify which layer imposed the limit.

For teams relying on Make as an iPaaS layer, this is the core of API rate limit handling in Make automation scenarios: identify the owner of the quota, understand Make’s default execution behavior, and design retries around the actual concurrency model rather than around an attractive but useless Sleep module.

Anatomy of the 429 Error: platform limits versus third-party quotas

A 429 response has a clear HTTP meaning, but its origin can be ambiguous. In a Make scenario, the request may be rejected because of a limit enforced by the external API, or because the Make account has reached a platform-level connection or operation boundary.

Those are different failures with different remedies.

A third-party API may impose limits per API key, user, tenant, IP address, endpoint, or time window. Some providers distinguish between read and write operations. Others apply stricter quotas to expensive endpoints, bulk operations, search requests, or authentication flows. Make does not erase those rules merely because the request is assembled visually. An HTTP module remains an HTTP client, and the destination service still sees the resulting request volume.

The other possibility is a restriction imposed by Make’s own platform or by the application connector operating inside it. The resulting symptoms can look similar: a module fails, the scenario stops, and the temptation is to add a delay. But a platform operation limit is not the same as an HTTP 429 returned by a remote service. In particular, OperationsLimitExceededError should not be collapsed into RateLimitError. The first concerns Make’s execution economics or platform boundaries; the second describes an HTTP request rejected for excessive frequency.

A retry mechanism is only intelligent when it knows which system is refusing the request.

The practical distinction can be summarized like this:

The table is not a substitute for inspecting the failed module. It is a guard against the most expensive category error: applying the same recovery policy to every red execution.

Why a quota can be exceeded even when the scenario looks small

A scenario can contain only one HTTP module and still produce a surprising number of requests. Iterators, repeated bundles, pagination, routers, search modules, and nested processing all multiply outbound traffic. A single webhook can carry a collection that is then expanded into dozens or hundreds of bundles. Each bundle may invoke the same downstream endpoint.

The visible canvas is therefore a poor measure of request pressure. The relevant quantity is the number and timing of outbound calls produced by the execution graph.

Several patterns are particularly prone to accidental bursts:

• An iterator expands a batch and immediately sends every item to the same API.
• Multiple routes converge on one provider without a shared pacing strategy.
• Several webhook executions arrive concurrently and each begins processing immediately.
• A scheduled scenario runs after a backlog has accumulated, producing a dense burst rather than a steady stream.
• A search-or-create workflow performs several API calls per business record, multiplying the effective request count.

The last case is frequently underestimated. If processing one record requires a lookup, a conditional write, and a follow-up update, the provider does not see one business action. It sees several requests. The business process may be simple; the API traffic is not.

Default Make behavior: what happens after throttling

Make has built-in behavior for rate limit errors, but it is not a universal replacement for architecture. The outcome depends on whether the scenario is scheduled or instant, and whether incomplete executions are enabled.

For a scheduled scenario with incomplete executions disabled, a rate limit error causes Make to pause the next scenario execution for 20 minutes. The failed attempt is not automatically rerun. This distinction matters. A pause of the schedule is not the same thing as recovery of the rejected bundle. The system has postponed the next run, but it has not necessarily replayed the request that failed.

That default can be acceptable for a low-value periodic synchronization where losing one execution is tolerable or where the source data will be discovered again on the next run. It is a poor fit for an order update, a customer notification, a financial record, or any workflow in which a failed bundle represents a state transition that must eventually be completed.

With incomplete executions enabled, Make can automatically rerun an execution that encounters a rate limit error. The retry process uses exponential backoff intervals: subsequent attempts are separated by progressively longer delays rather than being issued immediately in a tight loop.

This is a far more defensible default because it reduces the probability of turning one rejected request into a cascade of rejected requests. Yet it still leaves design questions unresolved:

• How many attempts are appropriate for the business operation?
• Is the operation idempotent?
• What happens if the provider’s quota window is longer than the retry sequence?
• Can a later retry create a duplicate record?
• Does the scenario have a backlog that will immediately reproduce the same burst?
• Is the error caused by Make or by the external service?

Automatic exponential backoff is a recovery primitive, not a complete rate-governance policy. It manages the timing of retries for a failed execution. It does not necessarily regulate all other executions running at the same time.

Scheduled scenarios and instant scenarios are not interchangeable

A scheduled scenario has a natural clock. It polls, processes, and waits for the next run. An instant scenario, such as one triggered by a webhook, is driven by arrival time and may receive multiple events in rapid succession.

That difference changes the shape of the problem. A scheduled workflow can be slowed at its execution boundary. A webhook-driven workflow may have many independent executions already in flight before the first one encounters a 429. Retrying one execution does not automatically serialize the others.

This is why a scenario that behaves perfectly under a manual test can fail under production traffic. The test sends one request. The real system receives a burst, expands payloads into bundles, and distributes them through several routes. The rate limit is a property of the combined traffic pattern, not of the single request that happened to succeed during testing.

Exponential backoff in no-code workflows: useful, but not magical

Exponential backoff is the standard response to a temporary rate limit because immediate repetition is usually the worst possible response. If the provider is enforcing a quota window, another request sent a fraction of a second later is unlikely to improve the situation. It merely consumes more attention and may prolong the period of rejection.

In practical terms, backoff creates increasing distance between attempts. Make’s automatic handling applies this behavior when incomplete executions are enabled and the error is recognized as a rate limit failure. The platform controls the retry intervals, which is convenient and appropriately conservative for many ordinary scenarios.

But a backoff algorithm cannot compensate for an unbounded source of traffic. If ten webhook executions each retry independently, exponential backoff has not created a queue. It has created ten delayed clients, each with its own retry schedule. Depending on the provider’s quota model, those retries may still collide.

A robust design therefore has two layers:

1. Recovery timing — how an individual failed request waits before trying again.

2. Traffic shaping — how the system controls the number of requests entering the provider at once.

Make’s built-in retry behavior addresses the first layer. The second requires scenario architecture.

Idempotency is the boundary between safe retry and data corruption

A retry is safe only when repeating the operation is safe.

Reads are generally easier to retry because repeating a lookup does not normally create a second resource. Writes are more complicated. A failed response does not always mean the provider failed to apply the operation. The network may have timed out after the remote system accepted the request. If the workflow retries a non-idempotent create operation, it may create a duplicate record.

This is not a specifically Make problem. It is a distributed-systems problem exposed by a visual automation tool.

Before enabling aggressive retries around a write operation, establish what identifies the business event uniquely. Depending on the provider, that may be an idempotency key, an external reference, a source event ID, or a deterministic lookup-before-create strategy. If the destination API offers no idempotency support, the workflow must be designed with the possibility that the first attempt succeeded even when Make recorded a failure.

The aesthetically pleasing workflow is not necessarily the reliable one. A compact chain of modules that retries every red branch can be more dangerous than a larger scenario that records state, checks for an existing result, and resumes deliberately.

Architecting custom error routes with Sleep and Resume

Make allows a scenario to handle errors through custom routes. For a 429 response, a common pattern is to attach an error handler containing a Sleep module, a cloned HTTP request, and a Resume module.

The intent is straightforward:

1. The original HTTP request receives a 429.

2. The error handler pauses execution.

3. A cloned request is attempted after the delay.

4. Resume returns control to the scenario if the retry succeeds.

This pattern is useful when the default behavior is too opaque or when the workflow needs a specific recovery path for one module. It can also make the scenario’s operational intent visible to the next engineer, which is not a trivial advantage. A retry policy hidden in platform behavior is harder to audit than one expressed directly in the scenario.

The Sleep module can delay execution for up to 300 seconds, or five minutes. That makes it suitable for modest pacing adjustments and short-lived quota pressure. It is not a general-purpose queue, and five minutes is not a universal answer to a provider’s rate window.

A custom route should be designed with more discipline than simply placing Sleep before a copied request. At minimum, decide:

• Which response codes enter the route?
• How many retries are allowed?
• What happens after the final failed attempt?
• Is the original request safe to repeat?
• Where is the failed payload recorded?
• Does the route preserve the original correlation or event identifier?
• How will an operator distinguish a permanent failure from a temporarily exhausted retry budget?

A practical custom retry shape

For a single HTTP module, the route can remain relatively simple:

• Route only the recognized 429 condition into the handler.
• Delay the retry with Sleep.
• Repeat the same request with the original payload and relevant headers.
• Resume only after a successful response.
• Send the exhausted retry to a durable failure path rather than silently dropping it.

The phrase “recognized 429 condition” matters. A generic error handler that catches all failures and retries them is brittle. A malformed JSON body, missing authorization, invalid resource identifier, or forbidden operation will not become valid merely because the scenario waited five minutes.

The retry route should also preserve the original context. When an iterator produces many bundles, the failed item must remain traceable to the source event or record. Otherwise, the scenario may technically recover while making operational diagnosis unnecessarily painful.

One Sleep module does not create serialization

This is the point at which many no-code workflows become misleadingly elegant. A Sleep module delays the bundle currently passing through that module. It does not necessarily place all incoming bundles into a single ordered queue. It does not automatically coordinate separate webhook executions. It does not impose a global request rate across every branch that calls the same API.

Suppose a webhook receives a burst of events. Each execution reaches the same downstream HTTP module and receives a 429. Each error route then invokes Sleep. The requests are delayed, but they remain independent. When their delays expire, several retries may be released near the same time. The scenario has paced individual bundles without controlling aggregate concurrency.

This is why handling webhook throttling in Make requires a different mental model from handling a single scheduled request. A webhook is an ingress mechanism, not a queue by default. If the destination has strict quotas, the architecture may need an intermediate persistence layer or a deliberately serialized processing stage. The events must be accepted, stored, and drained at a rate compatible with the provider rather than pushed directly into an API at arrival speed.

Sleep is a delay primitive. It is not a queue, a semaphore, or a global rate limiter.

Designing traffic control around the actual pipeline

Rate limiting should be addressed at the point where traffic is generated, not only where failures become visible. If a scenario routinely creates bursts, placing a Sleep module inside the error route treats the symptom after the provider has already rejected the request.

There are several architectural responses, each appropriate to a different level of complexity.

Reduce unnecessary calls before adding retries

The cleanest request is the one the scenario never sends. Review whether the workflow is performing redundant searches, fetching the same object repeatedly, or updating a record when the destination state has not changed.

Common reductions include:

• Carrying identifiers between modules instead of searching for the same record again.
• Filtering unchanged records before invoking a write operation.
• Consolidating fields into one supported update request rather than issuing several partial updates.
• Moving static reference data out of the hot path when it can be reused safely.
• Avoiding pagination requests after the required result has already been found.

This is not optimization theatre. Each redundant call consumes quota and increases the number of failure points in the scenario.

Shape batches instead of releasing them as bursts

An iterator followed by an immediate HTTP module is a classic burst generator. If the source contains a large collection, the scenario may produce a dense sequence of outbound requests. A controlled batch size, a delay between groups, or a separate processing stage can reduce pressure.

The correct batch shape depends entirely on the provider’s quota model, which is not uniform across Make applications or external APIs. There is no responsible universal number to insert here. The API owner sets the actual constraints, and the workflow should be built around those constraints rather than around folklore.

Where the provider supports bulk endpoints, one bulk request may be preferable to many individual calls. But bulk operations have their own payload limits, failure semantics, and partial-success behavior. Replacing many requests with one large request is not automatically elegant; it is elegant only when the endpoint’s contract supports it cleanly.

Separate ingestion from processing

For bursty webhook traffic, the more durable design is often a two-stage pipeline:

• The webhook accepts and records the event.
• A controlled worker scenario processes pending events against the rate-limited API.

This introduces persistence and operational overhead, but it also creates a genuine place to manage ordering, retries, dead-letter handling, and throughput. The workflow no longer depends on the external API being available at precisely the same rate as incoming events.

A two-stage design is particularly valuable when events cannot be lost and when downstream writes are not safely repeatable. The system can record the event first, then track processing state independently of the webhook response.

Make can be part of this architecture, but no-code does not abolish the need for a queue-like concept when the workload is bursty and the destination is strictly throttled. Calling every direct webhook-to-API chain an event-driven architecture is generous. Without buffering and controlled consumption, it is usually just synchronous coupling with a visual interface.

Observability: a retry without a record is a hidden failure

Automatic retries reduce visible errors, which is useful until they reduce visibility too far. A scenario that eventually succeeds may still be consuming excessive quota, delaying customer-facing actions, or approaching a permanent failure state.

Track enough information to answer basic operational questions:

• Which module received the 429?
• Which external service and endpoint rejected the request?
• Which source event or business record was affected?
• How many attempts have occurred?
• When was the next retry due?
• Did the provider return any retry guidance?
• Did the final attempt succeed, fail, or become ambiguous?
• Is the same record appearing repeatedly in the retry path?

The exact response metadata exposed by a connector varies. If the provider supplies a retry hint, use it where the integration makes that information available. Do not invent a fixed delay and assume it matches the provider’s quota window.

A useful failure path is not merely an email notification. It should preserve the payload or a durable reference to it, the error category, and the retry state. Otherwise, an operator receives the abstract fact that a scenario failed but lacks the material needed to replay or repair the business operation.

Retry budgets are better than infinite optimism

A retry route should have a finite budget. Endless retries create a self-sustaining failure loop that can consume operations, flood logs, and delay unrelated work. The budget may be expressed as a number of attempts, a maximum elapsed time, or both.

After the budget is exhausted, route the item to a controlled terminal state:

• a manual review queue,
• a stored failed-execution record,
• a notification enriched with the source identifier,
• or a later reconciliation scenario.

The correct choice depends on the business consequence of delay. A low-value enrichment call can be abandoned and retried during a later synchronization. A payment-related state change or fulfillment update may require a stronger reconciliation process.

The important point is that the scenario must distinguish “not yet successful” from “will never become successful without intervention.” A retry loop that cannot make that distinction is not resilient; it is merely persistent.

The limits of Make’s default handling

Make’s automatic handling is valuable because it avoids the most primitive failure mode: immediate repeated requests. Scheduled scenarios with incomplete executions disabled pause the next run for 20 minutes after a rate limit error, while scenarios with incomplete executions enabled can retry with exponential backoff. Those defaults cover a substantial portion of ordinary transient throttling.

They do not solve several harder cases:

• The external provider’s quota is lower than the scenario’s aggregate throughput.
• Multiple webhook executions retry concurrently.
• A non-idempotent write may already have succeeded before the error was recorded.
• A backlog is released in a burst after a temporary outage.
• The failed request is part of a multi-step transaction with partial side effects.
• The error is a Make platform limit rather than an external HTTP 429.
• The Sleep delay is shorter than the provider’s actual quota window.
• The scenario has no durable record of the failed business event.

The correct response is not to reject Make’s built-in behavior. It is to place it at the appropriate layer. Let automatic backoff handle ordinary transient failures where the execution is safe to retry. Add custom routes when the workflow needs explicit semantics. Introduce buffering and controlled processing when arrival rate and service rate are fundamentally different.

A disciplined pattern for API rate limit handling in Make

A mature scenario treats rate limiting as part of the integration contract, not as an embarrassing exception. The implementation can remain visually simple, but its assumptions should be explicit.

A sound design usually follows this sequence:

1. Identify the limiter. Determine whether the 429 originates from the external API or whether the failure is a Make-side operation or connection limit.

2. Measure the request shape. Count calls generated per bundle, per record, per scenario run, and across concurrent executions.

3. Remove redundant requests. Reduce searches, repeated reads, and unnecessary writes before adding more recovery machinery.

4. Enable incomplete executions where replay is safe. Make’s automatic exponential backoff is preferable to immediate repetition, but only for operations that can be retried safely.

5. Use custom error routes selectively. Sleep, a cloned request, and Resume can provide explicit recovery for a known 429 path.

6. Set a finite retry budget. Route exhausted attempts into a durable failure or reconciliation path.

7. Control concurrency at the source. Do not assume that delaying one bundle serializes every webhook execution or route.

8. Preserve idempotency and correlation data. A retry must remain connected to the original event and must not silently create duplicates.

9. Observe the retry system. Record enough context to distinguish transient pressure from a permanently invalid request.

This is less glamorous than drawing a compact automation canvas and declaring the workflow fault-tolerant. It is also the difference between a scenario that merely works in a demonstration and one that survives real traffic.

Final mandate: design for pressure, not just success

HTTP 429 errors are not mysterious. They are a direct consequence of sending requests faster than a permitted quota allows. The difficult part is not recognizing the status code; it is determining which layer imposed the limit and designing a recovery path that respects concurrency, idempotency, and business state.

Make provides useful primitives: a default 20-minute pause for scheduled scenarios when incomplete executions are disabled, automatic exponential backoff when incomplete executions are enabled, and a Sleep module capable of delaying a bundle for up to 300 seconds. These are solid building blocks. They are not a substitute for traffic shaping, durable state, or a queue.

The strict rule is simple: never mistake a delayed retry for a rate-limit architecture. Use backoff for transient recovery, custom routes for explicit control, and a real buffering or serialized processing design when webhook traffic can exceed the destination API’s capacity. Anything less is a brittle pipeline wearing the costume of resilience.