HTTP 429 errors: retries with exponential backoff without saturating an API
Published on 2026-10-26 by frfrand
Retry-After, jitter and idempotency in HTTP clients
Your bot queries an API and starts receiving 429 Too Many Requests. Retrying immediately a hundred times only makes the problem worse. The right thing is to read the limits and space out attempts, with a maximum and a bit of randomness.
Let's get down to earth: what it means, how to test it, and what happens when you use it with clients or real information. Most problems aren't fixed with a magic button, but with steps you can repeat and measure.
What HTTP 429 and exponential backoff are and why they matter
429 indicates that a limit defined by the server has been reached. Some responses include Retry-After, which can indicate seconds or an HTTP date. When there is no indication, an exponential backoff with jitter and an attempt limit can reduce pressure and prevent many clients from retrying at the same time.
One thing is for a demo to work for five minutes and another is to sustain a service every day. For that you need limits, permissions, activity logs, and procedures to resolve failures without improvising.
Implementation or diagnosis example
import random, time
def delay(attempt, retry_after=None):
if retry_after is not None:
return max(0, float(retry_after)) # sólo si es número de segundos válido
return min(30, 2 ** attempt) * random.uniform(0.5, 1.0)
for attempt in range(5):
# llamar a la API, revisar respuesta y salir si funcionó
time.sleep(delay(attempt)) # sólo cuando el intento necesita reintentoIt is a didactic reference, not a template you should blindly run in production. Replace the example values, choose identities with minimal permissions, and make sure no sensitive key ends up in a log or repository.
How I would put it to work
- Confirm if the limit is per user, token, account, or IP address.
- Read
Retry-Afterwhen it arrives and accept its valid date or seconds format. - For retryable errors, use a maximum number of attempts and backoff with jitter.
- Protect write operations with idempotency keys when the provider supports them.
- Store 429 metrics and adjust concurrency; retries do not replace respecting quota.
After each step, verify a concrete result: an authorized action, an HTTP status, a processed task, a recorded cost, or an established metric. If something does not work, check which was the first failure before retrying in a loop.
An example that may appear in a real project
An n8n automation sends reservation notifications via an external API. When its quota is reached, the queue keeps the jobs and retries them with delay, instead of creating fifty simultaneous requests.
If that application has multiple clients, separate contexts and resources. It is especially important when a chatbot or an agent can query data: the ease of connecting tools must not bypass privacy and authorization limits.
The most common error
Do not indiscriminately retry POST payments: you could duplicate charges if there is no idempotency. The illustrative code must integrate response checks and a real retry policy; it does not sleep after a successful call.
A configuration with good defaults helps, but does not eliminate the need for testing. For services that write data or trigger actions, consider retries, duplicates, and midway failures.
Where does ArduMaker come in?
In applications hosted on ArduMaker, you can use workers and queues to process retries without blocking web requests. Logging failures prevents confusing a provider limit with a VPS issue.
With ArduMaker you can host the backend on a VPS, deploy from Git, configure an HTTPS domain, and use database, service, and MCP tools according to the project. This makes it easier to bring operations together in one environment, although business rules and security remain the responsibility of the software.
What I would measure to know if it improved
I would not measure only "works/does not work." I would also review resource consumption, errors, response times, or API usage, depending on the functionality. Define a success metric before the change and compare it with the same scenario afterward.
If a piece of data seems strange, check the sample and the time window. An average can hide extreme cases, and a single successful run does not prove that an automation can handle thousands of requests.
Frequently asked questions
Do I need a large infrastructure to start? Not necessarily. First solve the problem with a simple architecture and measure the point where it starts to fall short.
What happens if the external provider fails? You need timeouts, a retry policy, and a useful response for the user. Do not assume external APIs are always available.
How do I maintain control? Log important events, separate permissions, and keep a proven procedure to undo changes or recover information.
References to follow
Final idea: Automating and measuring is worth it when you also know how to detect an error, limit its effects, and recover.