Make Rate Limit Error (429)? Why It Happens and How to Fix It

Last updated: July 2026

Table of contents

1. The 30-second answer
2. What a Make rate limit error means
3. What actually triggers a 429
4. How Make handles a rate limit on its own
5. Recovering on your terms with the Retry error handler
6. Preventing 429s: batch, sleep, and throttle
7. The other 429: your own Make webhook
8. Frequently asked questions
9. Sources

Your scenario was fine yesterday. Today it’s throwing a RateLimitError, or you’re seeing a raw HTTP 429 in the run history, and bundles are failing partway through a batch. A Make rate limit error usually doesn’t mean the connection or module is broken — it means the scenario, another integration, or the combined workload is sending requests faster than the API currently allows. The service is telling you to slow down, and the fix is about pacing, batching, and letting Make’s retry machinery do its job, not about a misconfigured module.

This guide covers what the error means, the handful of things that actually trigger it, how Make retries it automatically, how to recover on your own terms, and how to stop it coming back. It also covers the second, separate 429 you can hit — the one on your own Make webhook — because the two get confused constantly.

The 30-second answer

A RateLimitError is Make reporting that a third-party API returned HTTP 429 — too many requests in a short window. What to do, in order:

• Let Make retry it. Enable Store incomplete executions in the scenario’s settings — Make automatically retries incomplete executions caused by RateLimitError on a documented backoff schedule, because rate limits are usually temporary.
• Customize recovery by attaching a Retry error handler to the module. The failed bundle is stored as an incomplete execution, and you can configure Make to complete it automatically or leave it for manual resolution.
• Prevent recurrence by batching operations (use bulk Create/Update endpoints where they exist) and adding Sleep modules between calls so you stop hammering the API in a burst.
• Throttle the whole scenario with Maximum runs to start per minute on the schedule panel if an instant trigger is firing too often.

What a Make rate limit error means

Many third-party APIs enforce limits on how many requests they will accept during a given period — per second, per minute, per hour. Cross that threshold and the API rejects the next request with HTTP 429, “Too Many Requests.” Make catches that response and classifies it as a RateLimitError. It’s one of a small family of transient errors: the request wasn’t malformed and your scenario isn’t wrong, the service simply wants you to wait.

That classification matters. When Store incomplete executions is enabled, Make automatically retries incomplete executions caused by RateLimitError, ConnectionError, and ModuleTimeoutError — the platform treats the condition as temporary and likely to clear on its own, which, for a rate limit, it almost always does. Contrast that with a DataError or a DuplicateDataError, where retrying the same request would just fail the same way; those wait for you. Understanding which bucket your failure is in tells you whether to wait or to intervene. For the full map of error types, see Make error handling.

What actually triggers a 429

Three patterns cause the large majority of rate limit errors:

• Hitting a per-second or per-minute API limit. The most direct cause — you called the endpoint more times in the window than the service allows.
• Bulk operations that aren’t batched. A scenario that loops over 500 records and fires one API call per record will spike far above the rate ceiling. Where a supported bulk endpoint exists, the same work can often collapse into far fewer requests, subject to the API’s batch-size limit.
• Multiple scenarios hammering the same API at once. Each scenario may be under the limit on its own, but they share the same third-party quota. Two or three running concurrently against the same service can push the combined rate over the edge.

One subtlety worth testing rather than assuming: some services use a 5xx response when they are overloaded or throttling traffic, and depending on the app or module, Make may surface that as a connection-related or runtime error rather than RateLimitError. If a scenario is failing under load but the error type looks like a connection problem, the underlying cause may still be rate limiting. Read the third party’s error message before deciding — most APIs say plainly what they didn’t like. Our guide on Make connection not working covers that 5xx-versus-429 ambiguity, and if the failing call is an HTTP module specifically, Make HTTP module not working is the place to start.

How Make handles a rate limit on its own

With Store incomplete executions off and no error handlers, an unhandled error follows Make’s default Rollback behavior — the run stops and the data from that run isn’t kept. So the first move for any scenario that matters is turning on Store incomplete executions in the scenario’s settings.

With that enabled, Make saves the failed run as an incomplete execution and automatically retries it on a backoff schedule: the delays from the original failure run 1 minute, 11 minutes, 21 minutes, 51 minutes, then 1h 21m, 1h 51m, 4h 51m, and 7h 51m after the original run, for eight scheduled retry attempts in total. The spacing is deliberate — if the third party is having a longer outage, you don’t burn all eight retries in the first few minutes. Each retry re-runs from the failed module; the first one to succeed marks the entry Resolved and stops the rest. Make also caps parallel retries at three per scenario and won’t start them while the scenario is running, so the retry queue can’t create its own rate-limit problem. For how that stored-run queue behaves start to finish, see Make incomplete executions, and the retry categories in Make retry types.

Recovering on your terms with the Retry error handler

The automatic backoff schedule works, but its later retries are hours apart — fine for a background job, not for a high-value scenario you want back on its feet quickly. If you want retry behavior you can configure yourself, attach a Retry error handler to the affected module: right-click the module, choose Add error handler, select Retry, and configure Automatically complete execution — set it to Yes with a retry count and interval of your choosing (for example, three attempts, 15 minutes apart), or leave it at No to hold the bundle for manual resolution. The Retry handler requires Store incomplete executions to be enabled. It removes the failed bundle from the active flow, stores it as an incomplete execution, and allows the remaining bundles to continue.

Don’t Skip a rate-limit failure unless losing that bundle is acceptable. The Skip error handler removes the affected bundle from the flow and lets the scenario continue. Because a 429 normally means the requested operation was not completed, skipping the bundle can leave the intended record unwritten. Use the Retry error handler when the bundle should be stored and attempted again.

A useful production pattern puts a notification on the error path before the handler — a Slack message or a data-store log — so a human hears about sustained rate limiting immediately, while the bundle is still queued for retry. When the rate limit is a symptom of a bigger load problem (a traffic spike, a bot), that early signal is what turns a one-night incident into a five-minute fix.

Preventing 429s: batch, sleep, and throttle

Retrying is recovery; the real win is not tripping the limit in the first place. Three levers, roughly in order of impact:

Batch your operations. If the service offers a bulk Create or bulk Update endpoint, use it. Where a supported bulk endpoint exists, one batched request can often replace many individual record-level requests, subject to the API’s batch-size limit — the single biggest reduction in request rate you can make, and it usually costs fewer credits too. Any time a scenario loops and calls an API once per iteration, that loop is your first suspect.

Add Sleep modules between calls. Make’s Sleep tool pauses the scenario for a set number of seconds. Dropping a short Sleep between operations spaces requests out so a burst doesn’t slam the API all at once. It’s a blunt instrument — it does add wall-clock time — and the correct delay depends on the third party’s documented request limit. Calculate the spacing from that limit, then test it under realistic load rather than assuming a fixed one- or two-second delay will be sufficient.

Throttle the whole scenario. On the schedule panel there’s a Maximum runs to start per minute setting. If an instant trigger occasionally fires a flood of runs — a Shopify store that gets a burst of orders, say — capping runs per minute makes Make queue the surplus and process it at your chosen rate, smoothing the spike before it ever reaches the downstream API. Set it to a rate the third party can comfortably absorb.

If none of those bring you under the limit and the volume is genuinely high, that’s a signal to rethink the architecture — spread the work across time, or pull from a queue you control rather than reacting to every event the instant it arrives.

The other 429: your own Make webhook

There’s a second rate limit that gets confused with the third-party one: the limit on your own incoming Make webhook. Make documents a processing limit of up to 300 incoming webhook requests per 10-second interval. If you send more, Make returns HTTP 429 to the sender. This is rarely a problem for moderate traffic, but it bites when a third-party service fires a burst of events all at once (some platforms emit many events per action if you’re subscribed to all of them), when your own code triggers the webhook in a loop without throttling, or when you’re using a webhook for a high-frequency stream that should really be batched.

The fixes here are structural: throttle or batch requests before they reach Make, configure the sender to retry HTTP 429 responses with backoff, or place the events in a queue that your scenario can drain at a controlled rate. For workloads that don’t need immediate processing, a scheduled polling pattern can also smooth large bursts. And note that if your scenario uses the Webhook response module and you’ve set a scenario-level runs-per-minute cap, exceeding that cap returns 429 to the caller too — which is correct behavior for a well-behaved sender like Shopify, but something your own calling code has to be ready to back off and retry against. For everything upstream of a webhook that isn’t firing at all, see Make webhook not triggering.

Want the throttling and error-handling patterns ready to import? Grab the free Builder’s Companion Kit — cheat cards, ready-to-import blueprints, and the rate-limit and retry setups we reach for most — at Get the kit →. You’ll need a free Make account to import the blueprints; you can create one here.

Frequently asked questions

What does RateLimitError mean in Make? It means a third-party API returned HTTP 429 — too many requests in a short window. The request wasn’t malformed; the service is asking you to slow down. Make classifies it as a temporary error, and when Store incomplete executions is enabled, it retries the failed run automatically.

Does Make retry a rate limit error automatically? Yes, when Store incomplete executions is enabled. Make automatically retries incomplete executions caused by RateLimitError, ConnectionError, and ModuleTimeoutError on a backoff schedule, with eight scheduled retry attempts after the original run.

How do I stop getting 429 errors in Make? Reduce your request rate. Batch operations with bulk Create/Update endpoints where available, add Sleep modules between calls to space out bursts, and use the Maximum runs to start per minute setting to throttle an instant trigger that fires too often. Check for multiple scenarios hitting the same API at once.

Why is my Make webhook returning 429? Make documents a processing limit of up to 300 incoming webhook requests per 10-second interval. A burst from a third party or a loop in your own code can exceed it. Throttle or batch requests before they reach Make, have the sender retry 429 responses with backoff, or switch to a queue your scenario drains at a controlled rate.

Should I use the Skip error handler for rate limits? No. A 429 normally means the operation didn’t complete, and Skip removes the affected bundle from the flow, so the intended record may never be written. Use the Retry error handler instead — it stores the failed bundle as an incomplete execution and can complete it automatically or leave it for you to resolve.

My rate limit shows as a connection error — why? Some services use a 5xx response when they are overloaded or throttling traffic, and depending on the app or module, Make may surface that as a connection-related or runtime error rather than RateLimitError. Read the third party’s status code and error message to confirm the real cause. For a custom app, inspect the app’s error-response configuration and confirm which Make error type the response actually produces before relying on automatic retry.

Sources

Grounded in The Missing Manual for Make (MMS Vegas) — Chapter 11, “Error Handling and Incomplete Executions”; Chapter 7 on webhook and scenario-level rate limits; and Appendix C, “Common Errors” — and verified against the current Make documentation:

• Make Help Center — Introduction to errors and warnings
• Make Help Center — Overview of error handling
• Make Help Center — Incomplete executions
• Make Help Center — Automatic retry of incomplete executions
• Make Help Center — Retry error handler
• Make Help Center — Scenario settings
• Make Help Center — Schedule a scenario
• Make Help Center — Webhooks

About the author

Brian Kasday is a direct-response marketer with four decades in the trade who rebuilt his entire marketing capability as a one-person operation using AI and a low-cost software stack. He writes The Operator’s Library for MMS Vegas, including The Missing Manual for Make — the thorough, plain-language reference the platform’s own docs never quite became.