Errores HTTP 429: reintentos con backoff exponencial sin saturar una API
Publicado el 2026-10-26 por frfrand
Retry-After, jitter e idempotencia en clientes HTTP
Tu bot consulta una API y empieza a recibir 429 Too Many Requests. Reintentar de inmediato cien veces solo empeora el problema. Lo correcto es leer los límites y espaciar los intentos, con un máximo y un poco de aleatoriedad.
Vamos a bajarlo a tierra: qué significa, cómo se prueba y qué pasa cuando lo usás con clientes o información real. La mayoría de los problemas no se arregla con un botón mágico, sino con pasos que podés repetir y medir.
Qué es HTTP 429 y backoff exponencial y por qué importa
429 indica que se alcanzó un límite definido por el servidor. Algunas respuestas incluyen Retry-After, que puede indicar segundos o una fecha HTTP. Cuando no hay indicación, un backoff exponencial con jitter y un límite de intentos puede reducir la presión y evitar que muchos clientes reintenten al mismo tiempo.
Una cosa es que una demo funcione cinco minutos y otra es sostener un servicio todos los días. Para eso necesitás límites, permisos, registros de actividad y procedimientos para resolver fallos sin improvisar.
Ejemplo de implementación o diagnóstico
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 reintentoEs una referencia didáctica, no una plantilla que debas ejecutar a ciegas en producción. Sustituí los valores de ejemplo, elegí identidades con permisos mínimos y asegurate de que ninguna clave sensible termine en un log o repositorio.
Cómo lo pondría a funcionar
- Confirma si el límite es por usuario, token, cuenta o dirección IP.
- Lee
Retry-Aftercuando venga y acepta su formato válido de fecha o segundos. - Para errores reintentables, utiliza un máximo de intentos y backoff con jitter.
- Protege operaciones de escritura con claves de idempotencia cuando el proveedor las admita.
- Guarda métricas de 429 y ajusta la concurrencia; los reintentos no sustituyen respetar la cuota.
Después de cada paso, verifica un resultado concreto: una acción autorizada, un estado HTTP, una tarea procesada, un costo registrado o una métrica estable. Si algo no funciona, comprueba cuál fue el primer fallo antes de reintentar en bucle.
Un ejemplo que puede aparecer en un proyecto real
Una automatización n8n envía notificaciones de reservas mediante una API externa. Al alcanzarse su cuota, la cola conserva los trabajos y los reintenta con retraso, en lugar de crear cincuenta solicitudes simultáneas.
Si esa aplicación tiene varios clientes, separa contextos y recursos. Es especialmente importante cuando un chatbot o un agente puede consultar datos: la facilidad de conectar herramientas no debe saltarse los límites de privacidad y autorización.
El error más común
No reintentes indiscriminadamente POST de pagos: podrías duplicar cargos si no hay idempotencia. El código ilustrativo debe integrarse con comprobaciones de respuesta y política de reintentos real; no duerme tras una llamada exitosa.
Una configuración con buenos valores predeterminados ayuda, pero no elimina la necesidad de pruebas. Para servicios que escriban datos o disparen acciones, contempla reintentos, duplicados y fallos a mitad de camino.
¿Dónde entra ArduMaker?
En aplicaciones alojadas en ArduMaker, puedes usar workers y colas para procesar reintentos sin bloquear solicitudes web. Registrar fallos evita confundir un límite de proveedor con un problema del VPS.
Con ArduMaker puedes alojar el backend en un VPS, desplegar desde Git, configurar dominio HTTPS y utilizar herramientas de bases, servicios y MCP según el proyecto. Eso facilita reunir operaciones en un entorno, aunque las reglas de negocio y de seguridad siguen siendo responsabilidad del software.
Qué mediría para saber si mejoró
No mediría solo «funciona/no funciona». También revisaría consumo de recursos, errores, tiempos de respuesta o gasto de API, según la funcionalidad. Define una medida de éxito antes del cambio y compárala con el mismo escenario después.
Si un dato parece extraño, comprueba la muestra y la ventana temporal. Un promedio puede ocultar casos extremos, y una única ejecución exitosa no demuestra que una automatización soporte miles de solicitudes.
Preguntas frecuentes
¿Necesito una infraestructura grande para empezar? No necesariamente. Primero resuelve el problema con una arquitectura simple y mide el punto donde empieza a quedarse corta.
¿Qué pasa si falla el proveedor externo? Necesitas timeouts, política de reintentos y una respuesta útil para el usuario. No asumas que las APIs externas están siempre disponibles.
¿Cómo mantengo el control? Registra eventos importantes, separa permisos y conserva un procedimiento probado para deshacer cambios o recuperar información.
Referencias para seguir
La idea final: automatizar y medir vale la pena cuando también sabes detectar un error, limitar sus efectos y recuperarte.