n8n: cómo evitar el error 429 en tus workflows

Rate limiting y throttling: la diferencia que decide si tu workflow falla o solo espera

Imagina que una API permite 100 solicitudes por minuto y tu workflow envía la número 101 antes de que ese minuto termine. Con rate limiting, la petición se rechaza con un error 429 (Too Many Requests) y tu workflow tiene que decidir cuándo volver a intentarlo. Con throttling, el proveedor puede retener esa solicitud en una cola y procesarla más tarde.

Ese contraste —error contra demora— parece un detalle técnico, pero define cómo diseñas la automatización. En los dos casos el proveedor controla el límite. Lo único que está en tus manos es cómo responde tu workflow cuando lo cruza.

¿Quién impone el límite y quién se adapta?

Un rate limit fija un tope: cuántas solicitudes puede hacer un cliente en un periodo determinado. Cuando lo superas, el proveedor rechaza las peticiones adicionales, normalmente con un 429.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El throttling hace algo distinto: en lugar de dejar pasar todo de golpe, frena o retrasa el flujo. Las solicitudes pueden quedar en cola hasta que haya capacidad disponible. Eso no significa que tu petición falle porque la API esté bajo presión, pero sí puede tardar más en completarse — y tu workflow tiene que contemplar esa demora, sobre todo cuando los pasos siguientes dependen de esa respuesta.

La conclusión práctica es incómoda: no controlas la política de tráfico. Lo que sí controlas es el patrón con el que envías las solicitudes.

¿Cómo miden los proveedores tu tráfico?

"Demasiadas solicitudes" significa cosas distintas según cómo cuente cada API. Y esa diferencia cambia la forma en que debes espaciar tus llamadas.

Ventana fija: el tiempo se divide en intervalos. La API permite, por ejemplo, 100 solicitudes cada minuto y reinicia el contador al empezar el siguiente. Es fácil de entender, pero permite ráfagas justo en el borde entre dos ventanas.
Ventana deslizante: mide sobre un periodo que se mueve continuamente. No pregunta cuántas solicitudes hiciste desde que arrancó el cronómetro, sino cuántas hiciste en los últimos 60 segundos. Esperar a que el reloj cambie de minuto no te devuelve automáticamente todo tu cupo.
Token bucket: tu cupo es un balde que recibe tokens a ritmo constante. Cada solicitud gasta un token y los no usados se acumulan hasta un tope. Si se juntaron suficientes, puedes enviar varias solicitudes de golpe sin pasarte del límite.
Leaky bucket: funciona al revés. Las solicitudes entran a una cola y salen a un ritmo controlado, así que las ráfagas se suavizan en lugar de consumir capacidad acumulada.

Ningún patrón de envío funciona igual en todas las APIs. Antes de decidir cuán agresivo eres con el batching, lee la documentación de límites del proveedor.

¿Qué te dice realmente un error 429?

El código 429 (Too Many Requests) es la señal de que superaste el límite. La respuesta puede incluir además un encabezado Retry-After que indica cuánto debe esperar el cliente antes de volver a intentarlo.

Si el encabezado está, úsalo: es información del proveedor y es mejor que cualquier estimación propia. Si no está, tu workflow necesita su propia estrategia para espaciar los intentos. Ahí entra el backoff exponencial.

Backoff exponencial: esperar cada vez más, no siempre lo mismo

Reintentar de inmediato la misma solicitud reproduce el problema. El backoff exponencial rompe ese bucle aumentando la espera después de cada intento fallido: un segundo, luego dos, cuatro, ocho, y así sucesivamente.

Dos salvaguardas son obligatorias:

Un delay máximo y un límite de reintentos, para que un problema temporal de la API no deje tu workflow reintentando de forma indefinida.
Jitter, es decir, un poco de aleatoriedad en cada espera. Varios workflows que fallan al mismo tiempo tienden a reintentar al mismo tiempo; el jitter dispersa esos intentos y evita un nuevo pico de tráfico.

Hay una tercera condición que se pasa por alto con frecuencia: confirma que la solicitud sea segura de repetir. Las peticiones con efectos secundarios pueden ejecutar una acción dos veces, así que verifica si la API soporta idempotencia antes de reintentar de forma automática.

¿Cómo se aplican estos patrones en n8n?

n8n es una plataforma de automatización source-available y nativa de IA que permite resolver los límites de tres maneras: frenar las solicitudes antes de llegar al tope, reintentar después de un fallo o derivar los errores persistentes a otra ruta.

Pacing con batching: el nodo HTTP Request procesa los ítems en lotes y pausa entre ellos con los parámetros Items per Batch y Batch Interval. Para un control más fino, se combina Loop Over Items con un nodo Wait.
Retry on fail: permite reintentar automáticamente un nodo fallido y configurar la espera entre intentos, para no reenviar la misma solicitud de inmediato.
Error workflows: cuando los reintentos se agotan, un Error Trigger puede lanzar un workflow dedicado para registrar, alertar o ejecutar un paso de recuperación, en lugar de dejar que el fallo desaparezca en el historial de ejecuciones.

La secuencia recomendada es esa: primero pacing, después reintentos y, por último, manejo de errores como red de seguridad.

El ecosistema alrededor de n8n se movió en esa dirección. El 12 de octubre de 2026, ZoomInfo anunció una integración nativa con n8n como nodo verificado dentro de la plataforma, según reportó Yahoo Finance. El nodo permite consultar en tiempo de ejecución datos verificados de más de 100 millones de empresas y 500 millones de contactos, y funciona también como herramienta que un agente de IA puede invocar por su cuenta. "Con el nodo verificado de ZoomInfo dentro de n8n, los equipos pueden traer inteligencia actual de empresas y contactos en tiempo de ejecución", dijo Hugues Vincent, Head of Partnerships de n8n.

Más datos por workflow, más llamadas a APIs externas, más probabilidad de chocar con un 429. La integración es una buena noticia para la productividad y, a la vez, una razón más para tratar el manejo de límites como parte del diseño y no como un parche posterior.

Si tú expones la API, el problema también es tuyo

Del otro lado del mostrador la lógica se invierte. Neil Madden, security director de ForgeRock, plantea en API Security in Action que el rate limiting es un control de seguridad, no solo de rendimiento: ayuda a prevenir ataques de denegación de servicio y a garantizar la disponibilidad del servicio, según el extracto publicado por TechTarget.

Su recomendación operativa es aplicar el límite lo antes posible, idealmente en un balanceador de carga o proxy inverso, antes de que las solicitudes lleguen a los servidores de la API. Y el límite de cada servidor debería ser una fracción del objetivo global: si el servicio debe atender mil solicitudes por segundo repartidas en diez servidores, el tope por servidor ronda las cien por segundo, según el mismo criterio.

¿Qué significa esto para tu startup?

Un pico de errores 429 puede detener un workflow que funcionaba bien hasta ayer. Estas son las acciones que puedes tomar esta semana:

Audita tus integraciones críticas. Abre la documentación de límites de cada API que consumes y anota el modelo que usa (ventana fija, deslizante, token bucket). Sin ese dato estás adivinando el tamaño de tus lotes.
Prioriza el pacing sobre el retry. Ajusta Items per Batch y Batch Interval para que el tráfico salga por debajo del tope. Prevenir es más barato que recuperar.
Respeta el Retry-After y añade jitter. Si el proveedor te dice cuánto esperar, obedécelo. Si no, usa backoff exponencial con un tope de delay y de intentos.
Verifica la idempotencia antes de reintentar. Un reintento automático sobre una operación con efectos secundarios puede duplicar un cobro, un correo o un registro en el CRM.
Rutea los 429 persistentes a un workflow de error. Un fallo silencioso en el historial de ejecuciones es un incidente que descubres tarde y mal.

Conclusión

No puedes negociar los límites que impone una API, pero sí puedes decidir cómo responde tu automatización. La diferencia entre un workflow frágil y uno resiliente casi nunca está en la lógica de negocio: está en cómo espacias las solicitudes, cuánto esperas entre reintentos y qué haces cuando el proveedor te dice que pares.

Empieza por leer la documentación de límites de tu API más crítica, ajusta el batching y deja el backoff como red de seguridad. Es trabajo de una tarde y te ahorra el incidente que nadie quiere explicar.