Hola a todos,
Estoy creando flujos de trabajo en n8n que dependen en gran medida de APIs externas, e intento encontrar una forma confiable de manejar límites de velocidad sin ralentizar todo el flujo de trabajo.
Por ejemplo, una API podría devolver: {
“status”: 429,
“message”: “Too Many Requests”,
“retry_after”: 30
}
Mis principales preocupaciones son: Evitar reintentos innecesarios
Respetar los límites de velocidad de la API
Evitar que una API lenta bloquee otros flujos de trabajo
Manejar fallos temporales sin perder datos
Estoy considerando retroceso exponencial, colas de solicitudes y limitación de concurrencia.
Para quienes ejecutan n8n en producción:
¿Cómo manejan normalmente las respuestas 429?
¿Usan una cola o simplemente reintentan con retrasos?
¿Cómo deciden el número máximo de reintentos?
¿Han encontrado una buena forma de evitar que una API se convierta en un cuello de botella para toda la instancia de n8n?
Describe el problema/error/pregunta
¿Cuál es el mensaje de error (si la hay)?
Por favor comparte tu flujo de trabajo
(Selecciona los nodos en tu lienzo y utiliza los atajos de teclado CMD+C/CTRL+C y CMD+V/CTRL+V para copiar y pegar el flujo de trabajo.)
Comparte el resultado devuelto por el último nodo
Información sobre tu configuración de n8n
Versión de n8n:
Base de datos (predeterminada: SQLite):
Configuración de EXECUTIONS_PROCESS de n8n (predeterminada: own, main):
Ejecutando n8n a través de (Docker, npm, n8n cloud, aplicación de escritorio):
Hola @Greg_John Un buen enfoque en producción es tratar los límites de velocidad como un comportamiento esperado en lugar de simplemente reintentar todo inmediatamente.
Solicitud de API
↓
¿429 / Error Temporal?
↓ Sí
Esperar + Retroceso Exponencial
↓
Reintentar
↓
¿Se alcanzó el máximo de intentos?
↓ Sí
Flujo de trabajo de letra muerta / error
Enfoque recomendado
Respeta el valor Retry-After de la API cuando se proporciona
Utiliza retroceso exponencial para fallos temporales
Establece un recuento máximo de reintentos
Limita las solicitudes concurrentes a la API
Envía los trabajos que fallaron permanentemente a un flujo de trabajo de error/recuperación
Por ejemplo: Reintento 1 → 2 segundos
Reintento 2 → 4 segundos
Reintento 3 → 8 segundos
Reintento 4 → 16 segundos
Los retrasos exactos deben depender de los límites de la API.
La clave es evitar tormentas de reintentos. Si cientos de ejecuciones reciben un 429 al mismo tiempo y todas reintentan inmediatamente, puedes empeorar aún más el problema.
Para sistemas de alto volumen, combinar límites de concurrencia + retroceso exponencial + una ruta de recuperación generalmente proporciona una configuración mucho más confiable.
@Greg_John Las solicitudes HTTPS tienen tiempos de reintento con una espera, podrías usar eso para ayudarte, pero no puedes hacer que los límites de velocidad sean más rápidos a menos que tengas un plan superior. Puedes configurarlo para que hagan lotes, y reintenten en caso de fallo, ¡+ los nodos de espera te ayudarán!
¡configurar flujos de trabajo de errores también puede ayudarte a monitorearlo más fácilmente!
Buenas respuestas arriba. Algunas cosas que abordan específicamente tu preocupación sobre una API lenta que bloquea otros flujos de trabajo:
Aislar la ejecución por API con sub-flujos de trabajo
La idea clave: no manejes límites de velocidad dentro de tu flujo de trabajo principal. Mueve cada llamada a API externa a su propio sub-flujo de trabajo (nodo Execute Workflow). Tu flujo principal se mantiene rápido; el sub-flujo de trabajo maneja su propia lógica de reintentos y puede ejecutarse de forma independiente sin bloquear otras ejecuciones paralelas.
Rastrear el estado de cuota entre ejecuciones
El reintentos HTTP incorporado solo maneja fallos transitorios. Para una verdadera gestión de límites de velocidad entre ejecuciones concurrentes, necesitas un estado que persista entre ejecuciones:
Antes de la llamada a la API, lee la cuota restante desde un almacén clave-valor (fila de Airtable, Redis a través de HTTP, o una hoja de Google)
Si la cuota está cerca de agotarse, escribe una marca de tiempo «cooldown hasta» y omite
Después de una llamada exitosa, decrementa el contador
Esto evita que múltiples ejecuciones de flujo de trabajo concurrentes saturen la misma cuota de API simultáneamente.
Patrón de disyuntor
Agrega una verificación de disyuntor al inicio de tu sub-flujo de trabajo de API:
Lee una marca «estado del circuito» desde tu almacén KV
Si está abierto (activado después de N 429 consecutivos), devuelve un error estructurado inmediatamente sin tocar la API
Un flujo de trabajo programado por separado reinicia la marca después de que expira el cooldown
Esto es lo que evita que una API limitada cause fallos en cascada en todo lo que depende de ella.
Cola de letras muertas
Después de los reintentos máximos, no solo registres el error — escribe el payload fallido en una tabla de Airtable o una cola de webhooks. Un flujo de trabajo de recuperación separado reintenta estos según un cronograma, o los marca para revisión en Slack.
El enfoque de backoff exponencial + nodo Wait que @Niffzy describió es sólido para la capa de reintentos. La capa de circuit breaker + estado externo es lo que lo hace seguro para producción cuando múltiples flujos de trabajo comparten la misma cuota de API.
Si esto es para un sistema donde los fallos tienen costo real (pedidos perdidos, desencadenadores omitidos), este es el tipo de arquitectura que manejamos en compilaciones personalizadas en occelatus.io/automate. Feliz de responder preguntas aquí de cualquier forma.
Buenos consejos anteriores sobre backoff y aislamiento de subflujos. Tres cosas que causan problemas en producción y que aún no se han mencionado.
No reintentar cada fallo. Solo 429 y 5xx merecen reintentarse. Un 400, 401 o 403 fallará de forma idéntica en cada intento, así que reintentar solo consume tu presupuesto de reintentos y hace que una credencial incorrecta parezca un problema de límite de velocidad. Ramifica según el código de estado antes de la lógica de reintento, no después. Esta es la causa más común de “mis reintentos no ayudan”.
Añade jitter al backoff. El backoff exponencial simple significa que cada elemento paralelo que fue limitado en el mismo momento reintenta en el mismo momento, y vuelves a desencadenar el límite de forma sincronizada. Aleatoriza cada retraso en algo como más o menos 30 por ciento. Con diez elementos concurrentes, esta es la diferencia entre recuperarse en el segundo intento y thrashing durante un minuto.
Haz que las escrituras reintentadas sean idempotentes. Este es el que realmente cuesta dinero. Si un POST agota el tiempo o devuelve 502, a menudo no sabes si el servidor lo procesó. Reintentar puede crear el registro dos veces. Si la API admite una clave de idempotencia, envía una y reutilízala en los reintentos de la misma operación lógica. Si no, comprueba el registro antes de escribir en cualquier intento después del primero. Reintentar una lectura es gratis; reintentar una escritura no.
Una cosa más sobre tu ejemplo retry_after: 30: honra ese valor en lugar de tu propia curva de backoff cuando la API lo envía. También vale la pena saber que hay dos situaciones diferentes detrás de un 429, y requieren respuestas diferentes. Un límite de ventana por endpoint significa que la cuota se agota hasta un tiempo de reinicio fijo, así que la única solución es esperar y establecer el ritmo de tu tasa de solicitud. La limitación general del servicio significa que simplemente estás enviando demasiado rápido en este momento, así que el backoff más la concurrencia más baja lo resuelve. Si la respuesta lleva una marca de tiempo de reinicio estás en el primer caso; si solo lleva Retry-After generalmente estás en el segundo.
