How to Call APIs Without Getting Blocked

If you have ever seen an HTTP 429 Too Many Requests in production, you know it is not just another error.

It does not break anything all at once.

It is not a 500.

But it is a clear warning:

“You are going too fast. Stop.”

And if you keep ignoring it, the next thing is no longer a 429.

It is a temporary block, or worse, an IP ban.

In this article we are going to look at how to avoid the 429 error, how to stop hammering an API, and which patterns “polite” systems use to live alongside third party APIs without ending up on a blacklist.

What the 429 error is and why it shows up

The 429 Too Many Requests error means exactly what it says:

you have gone over the number of requests the API considers reasonable within a time window.

But careful:

it is not always a fixed number like “100 requests per minute”.

Plenty of APIs also look at things like:

• sudden spikes (everything at once)
• synchronised retries
• too many concurrent connections
• “weird” patterns that look like bots

That is why you sometimes think:

“I have not gone over the limit… why am I getting a 429?”

Because the problem is not only how much you call, but how you call.

The classic mistake: treating an API as if it were infinite

Most blocks do not come from high, steady usage.

They come from artificial spikes.

A typical example:

• your system boots up
• or there is an event at 09:00
• or something fails and you retry everything at once
• boom: hundreds or thousands of requests in seconds

From your side: “all normal”.

From the API’s side: you look like an attack.

This is where the important patterns come in.

Jitter: stop doing everything at the same time

Jitter is a fancy word for something very simple:

add a bit of randomness to your timing.

Without jitter:

• 500 requests fail
• all of them wait 30 seconds
• all of them retry at exactly 30 seconds
• all of them fail again at the same time

With jitter:

• one waits 31s
• another 47s
• another 62s

The result:

the same amount of work, spread out over time.

APIs hate synchronised stampedes.

Jitter defuses them almost like magic.

Backoff: the worse it goes, the less you push

Backoff means that every failure makes you wait longer before retrying.

It is not punishment.

It is manners.

A typical pattern:

• first failure → quick retry
• second failure → you wait longer
• third failure → you wait quite a bit longer
• fourth failure → you stop or mark it as failed

If an API is struggling right now, odds are it will still be struggling five seconds from now.

Pushing harder helps nobody.

Retry-After: when the API talks to you, listen

Some APIs, when they return a 429, include a header:

Retry-After: 120

Translation:

“Do not call me before 120 seconds.”

That is not a suggestion.

It is an implicit contract.

Ignoring Retry-After is one of the fastest ways to get properly blocked by an API.

If it is there, you respect it.

Always.

Circuit breaker: knowing when to stop

One of the biggest mistakes in distributed systems is not knowing when to stop calling.

That is what the circuit breaker is for.

The idea is simple:

• you detect many failures in a row
• you stop calling for a while
• then you test carefully
• if it is still bad, you stop again

Typical states:

• Closed: business as usual
• Open: the API is not called
• Half-open: you test with a few requests

This protects:

• the API
• your system
• your IP

A system that knows how to stop looks mature. One that keeps pushing looks like a bot.

Ramp-up: do not start out shouting

Another suspicious pattern: going from 0 to 500 requests in one second.

Even if you are allowed to.

Ramp-up means increasing the load little by little:

• you start with few concurrent requests
• you increase gradually
• you reach the ceiling progressively

This matters especially:

• after restarts
• after deployments
• after an outage
• after a circuit breaker

Seen from outside, your traffic looks normal.

That counts for more than you think.

Throttling API calls is your job too

Not everything depends on the external API.

Your system should:

• control its own concurrency
• cap requests per second
• avoid retry loops
• cache responses when it makes sense

If you know a piece of data does not change every second, do not ask for it every second.

This cuts down on:

• 429s
• latency
• cost
• and headaches

Monitor, or you are flying blind

If you do not measure, you have no idea why you are being blocked.

At a minimum you should be able to see:

• how many 429s you get
• when they happen
• how many retries you make
• how long requests sit in the queue

A lot of rate limit problems get solved just by looking at a graph.

The invisible pattern: looking polite

None of this is about “squeezing limits”.

It is about behaving like a good network citizen.

A polite system:

• does not push when it is told no
• does not retry everything at once
• does not create artificial spikes
• knows how to stop
• comes back gradually

APIs do not usually punish steady volume. They punish erratic behaviour.

Conclusion

The 429 Too Many Requests error is not your enemy.

It is a signal.

It is telling you:

“Slow down and think a bit harder about how you are calling.”

If you apply:

• jitter
• backoff
• Retry-After
• circuit breaker
• ramp-up
• and concurrency control

you not only stop APIs from blocking you, you also build more stable, more professional systems.

If this article was useful, share it with someone who is fighting a 429 in production right now.

You will probably save them the trouble.