HTTP 429: the error that makes your automation lie to you

The dashboard said success, the database disagreed

We once spent two days helping a client figure out why their nightly sync kept losing contacts. Every morning the run finished, the status went green, and everyone moved on. But a few hundred records never made it from their shop into their CRM. Different ones each night. No pattern anyone could see.

What made it maddening was that nothing looked broken. The workflow was sensible. The mapping was right. There was no red error anywhere. The data just leaked.

The culprit was a number almost nobody in the no-code world thinks about until it bites them: HTTP 429, "Too Many Requests." Partway through each run, the CRM's API got tired of being hammered and started refusing calls. The automation treated those refusals as if they were fine and kept going. Every contact that happened to be in flight at that moment vanished without a trace.

In our experience, rate limits are the single most common reason an automation appears to work and still loses data. And almost no one designs for them up front.

What a rate limit actually is

Every API worth using puts a cap on how often you can call it. The exact rules differ by provider, but the idea never changes: send too many requests too fast and instead of your data you get a 429 back.

This is not a bug. It is the provider protecting its own infrastructure and making sure one noisy customer cannot drag down everyone else. Many APIs are even polite about it. They include a header called "Retry-After" that tells you, in plain seconds, how long to wait before trying again. It is about the most honest thing an API can say to you, and most workflows ignore it completely.

Why no-code makes this worse

Write code by hand and a failing API gets in your face fast. Something throws, the program stops, you deal with it. No-code tools take that friction away, which is exactly why they feel pleasant to use and exactly why this problem hides so well.

Drop a module in Make that loops over 5,000 records and calls an API for each one, and it looks innocent in the editor. One loop, one module, done. What you cannot see is that those 5,000 calls fire as fast as the platform can push them. If the API allows two requests per second, you are over the line within the first second.

Then comes the part that really hurts. Most builders set up their workflows so a single failed call does not kill the whole run, which is reasonable. So the failure gets skipped quietly. As far as the tool is concerned, everything is fine. As far as your data is concerned, every record that caught a 429 is simply gone. Green on the dashboard, hole in the database.

Three ways it shows up

The first is silent loss. Individual records disappear, nobody notices right away, and when they finally do, the cause is hard to track down because nothing actually looks wrong.

The second is the half-finished sync. The run goes fine until the API hits its limit, and everything after that point never arrives. This gets nasty when your data is sorted, by name or by date, because then the same slice goes missing every time and it looks like a whole part of your business stopped existing.

The third is the retry death spiral. The tool notices a call failed and immediately tries again. And again. Each retry is one more request against a limit you are already blowing past. Instead of backing off, the system digs itself deeper. With some providers, every extra attempt makes the lockout longer.

How to do it properly

You do not need to be an engineer to fix this. You just need to stop pretending every API can take infinite punishment.

Slow down on purpose. Put a deliberate gap between calls. If the API allows two per second, do not throw a hundred at it at once. A few hundred milliseconds of waiting between calls feels like wasted time and is the difference between a sync that finishes and one that starves halfway through.

Listen to the answer. When an API returns a 429 and the Retry-After header says wait ten seconds, wait ten seconds. Not a guess, not an instant retry. Take the number the provider hands you and respect it. That one habit solves a surprising share of all rate limit trouble.

Retry with growing patience. When you do try again, space the attempts out. One second, then two, then four. Engineers call this exponential backoff, and it is really just the recognition that an overloaded system needs more breathing room, not less.

Ask less in the first place. Often the cleanest fix is to make fewer calls at all. Do you really need a separate request for every single contact, or can the API take a hundred at once? Plenty of APIs offer batch endpoints that move large chunks of data in one call. That beats perfecting your throttling almost every time.

What each tool gives you

Make lets you set how many operations run at once per scenario and drop in a Sleep module for deliberate pauses. An iterator plus a small wait is often most of the battle. The key is to not leave error handling on "ignore," but to treat a 429 as what it is: a "try me again soon," not a "forget it."

n8n gives you more control, because the HTTP Request node lets you configure retries with wait times directly. Many of the prebuilt integration nodes handle rate limits on their own, the generic HTTP node does not, and that is where most of the trouble starts. If you self-host, you can also cap concurrency globally.

Zapier gives you the least control and does the most for you behind the scenes. With large volumes you hit the ceiling fast, and the only reliable lever is usually to spread the load over time instead of cramming everything into one run.

How to tell if this is already happening to you

You do not need to read any code to check. You just need to look in the right places. For a single run, compare the number of records going in with the number coming out. If 5,000 go in and 4,700 arrive, and no rule explains the missing 300, you have a strong lead.

Then open your platform's execution log and filter for status code 429 or for messages mentioning "rate limit" and "too many requests." In Make and n8n those responses sit in the run history even when the workflow reported green at the end. Watch for one telltale pattern: do the failures cluster at the end of long runs, or right when several automations hit the same API at once? If so, your logic is not the problem. The volume is.

Where it gets decided

Rate limits are not some edge-case footnote. They are the point where you find out whether an automation grows with your business or falls over the first time it meets a serious amount of data. Sync ten records a night and you will never notice. Sync ten thousand and the weak builds give themselves away.

Our advice is unglamorous. Build every workflow that makes more than a handful of calls as if the API will eventually say no, because it will. The only question is whether your system is ready for it, or whether you find out on a Monday morning with 600 contacts missing and nobody able to say why.