Gestionar los límites de tasa de la API: Wait, Batching, Retry, Pagination

Quien construye sus propios workflows contra APIs de terceros tarde o temprano se topa con la respuesta 429: «Too Many Requests». Precisamente en el procesamiento masivo, por ejemplo al enriquecer cientos de contactos de CRM o al sincronizar grandes catálogos de productos, esto no es una excepción, sino la regla. n8n trae para ello varias herramientas integradas que se pueden combinar: el nodo Wait, el ajuste Retry on Fail del nodo HTTP Request, el Batching y el control de paginación. Actualizado: julio de 2026.

El truco no es encontrar una única función que «resuelva» los límites de tasa, sino elegir la combinación correcta para cada caso de uso. Una única llamada a la API con un fallo ocasional necesita algo distinto que un bucle sobre diez mil registros. A continuación repasamos ambos escenarios, basándonos en la documentación oficial de n8n.

Cómo reconocer un problema de límite de tasa

Según la documentación de n8n sobre límites de tasa un servicio suele reportar demasiadas solicitudes con el código de estado HTTP 429 y un mensaje de error indicando que el servicio está recibiendo «demasiadas solicitudes de tu parte». Este mensaje aparece en la salida del nodo cuando una solicitud falla, y es la primera señal de que no son las credenciales ni la URL las que están mal, sino simplemente que se envían demasiadas solicitudes en muy poco tiempo. Importante para la resolución de problemas: un 429 también puede aparecer en medio de un workflow que antes funcionó sin errores cientos de veces, por ejemplo porque un proveedor externo endurece temporalmente su límite durante una campaña o un pico de tráfico. Quien trabaje con frecuencia con la misma API debería conocer su documentación de límites de tasa antes de que el workflow pase a producción.

Retry on Fail: repetir automáticamente solicitudes individuales

Para workflows con errores 429 ocasionales y no sistemáticos, suele bastar con la lógica de reintento integrada en el nodo HTTP Request. En los Settings del nodo activas Retry On Fail y defines dos valores:

• Max Tries determina cuántas veces reintenta n8n como máximo la solicitud tras un fallo.
• Wait Between Tries (ms) determina la pausa entre los intentos, en milisegundos.

Según la documentación sobre problemas comunes del nodo HTTP Request si utilizas este ajuste específicamente contra límites de tasa, deberías establecer Wait Between Tries (ms) en un valor superior al límite del servicio. Si una API permite, por ejemplo, una solicitud por segundo, establece 1000 milisegundos para que el segundo intento no vuelva a caer en el mismo límite. La ventaja de este método: se hace con pocos clics en el mismo nodo, sin nodos adicionales en el lienzo. La desventaja: con muchos items en un bucle, el tiempo de espera se multiplica rápidamente, y sin control adicional, n8n sigue disparando tantas solicitudes como sea posible antes de que llegue siquiera el primer error.

Batching en el nodo HTTP Request: frenar las solicitudes de forma deliberada

Si sabes de antemano que una API tiene límites estrictos, tiene más sentido controlar preventivamente la tasa de solicitudes en lugar de solo reaccionar a los errores. Para ello, el nodo HTTP Request ofrece bajo Add Option > Batching dos ajustes:

• Items per Batch: cuántos items de entrada se procesan por ronda de solicitudes.
• Batch Interval (ms): la pausa entre los lotes, en milisegundos.

Según la documentación, esta opción de batching equivale funcionalmente a la combinación de Loop Over Items y el nodo Wait, solo que integrada en un único nodo. Si por ejemplo quieres enviar una solicitud por segundo a un servicio, establece Batch Interval (ms) en 1000. Para APIs con límites por minuto en lugar de por segundo, conviertes en consecuencia, por ejemplo 60 solicitudes por minuto dan un intervalo de 1000 milisegundos entre solicitudes individuales, o un intervalo mayor con varios items por lote. Para el procesamiento masivo, este es el ajuste base más robusto, porque ataca el problema de raíz en lugar de reaccionar solo tras un fallo.

Loop Over Items y el nodo Wait: control total sobre el ritmo

Para los casos en los que necesitas tu propia lógica entre lotes, por ejemplo un registro, una rama condicional o un ajuste dinámico del tiempo de espera según la respuesta, combinas Loop Over Items con tu propio nodo Wait. La estructura: coloca Loop Over Items antes de la llamada a la API, después inserta el nodo Wait y conecta su salida de vuelta a Loop Over Items. Así se crea un bucle que hace una pausa deliberada después de cada lote o cada item individual, antes de que empiece la siguiente ronda.

El propio nodo Wait está, según la documentación de n8n sobre el nodo Wait diseñado para pausar una ejecución en curso y retomarla después con los mismos datos en el punto donde se interrumpió. Para el tema de los límites de tasa, es especialmente relevante el modo After Time Interval: indicas un período de tiempo en segundos, minutos, horas o días, y el workflow se pausa exactamente ese tiempo. Importante saber: con tiempos de espera inferiores a 65 segundos, n8n no traslada los datos de ejecución a la base de datos, por lo que la pausa se ejecuta de forma ligera en memoria. Con tiempos de espera más largos, n8n se encarga automáticamente del almacenamiento en caché, lo que hace que el workflow se pueda reanudar de forma fiable incluso tras reinicios de la instancia. Además de After Time Interval el nodo también admite At Specified Time, On Webhook Call y On Form Submitted, pensados para otros escenarios como aprobaciones externas o ejecuciones programadas, pero rara vez necesarios para el rate limiting puro.

Controlar bien la paginación en lugar de cargarlo todo de una vez

Una causa frecuente de errores de límite de tasa no es en realidad la frecuencia de las solicitudes, sino su cantidad: quien intenta paginar diez mil registros en una sola pasada sin freno produce en poco tiempo muchísimas solicitudes seguidas. Según la documentación de n8n sobre paginación el nodo HTTP Request admite diferentes modos para ello:

• Response Contains Next URL: la API devuelve directamente en su respuesta la URL de la página siguiente, que lees mediante una expresión, por ejemplo `{{ $response.body["next-page"] }}`.
• Update a Parameter in Each Request: tú mismo incrementas un parámetro de query o de cuerpo entre las solicitudes, por ejemplo con `{{ $pageCount + 1 }}` para un conteo que empieza en cero, que debe ajustarse a una paginación de API que empieza en uno.

La documentación señala explícitamente que cada API implementa la paginación de forma distinta. Por eso deberías comprobar antes si el servicio trabaja con URLs siguientes, con números de página o con parámetros de offset, y cuántos resultados por página se permiten como máximo. El tamaño de página normalmente lo defines mediante tu propio parámetro de query como `limit` en los ajustes del nodo. Si combinas la paginación con Batching o con un nodo Wait entre las solicitudes de página, evitas que una exportación de datos extensa alcance el límite solo por su velocidad, antes incluso de que empiece el procesamiento propiamente dicho.

Patrones prácticos: qué combinación para cada caso

En la práctica vale la pena hacer una clasificación aproximada de qué herramienta aplica y cuándo:

• Errores 429 ocasionales con volumen bajo: Retry On Fail con un Wait Between Tries adecuado suele bastar.
• Límite de tasa conocido y fijo con volumen alto: Batching en el nodo HTTP Request con un intervalo acorde al límite del servicio.
• Lógica más compleja entre las llamadas, por ejemplo pausas dinámicas según la cabecera de respuesta o ramas adicionales: Loop Over Items combinado con un nodo Wait propio.
• Grandes volúmenes de datos en varias páginas: elegir un modo de paginación acorde a la API y además suavizarlo con Batching o Wait.

En la práctica, rara vez basta una sola herramienta para un workflow completo. Un patrón típico es la paginación para la obtención de datos, un intervalo de lote moderado durante el procesamiento y, además, Retry On Fail como red de seguridad para los momentos en que incluso la tasa frenada sigue provocando un 429 aislado. Así mantienes el control sobre el ritmo y la fiabilidad de tu workflow, en lugar de confiar en la suerte de que el proveedor externo nunca esté bajo carga.

Preguntas frecuentes

¿Cuál es la diferencia entre Retry On Fail y Batching?

Retry On Fail solo reacciona después de que una solicitud ya ha fallado, y la repite tras un tiempo de espera fijado. Batching actúa antes y frena desde el principio cuántas solicitudes salen y con qué intervalo. Para límites conocidos y fijos, Batching es la solución más limpia; para fallos ocasionales e imprevisibles, Retry On Fail lo complementa como refuerzo.

¿A partir de qué tiempo de espera el nodo Wait guarda la ejecución en la base de datos?

Según la documentación de n8n, el nodo Wait solo traslada los datos de ejecución a la base de datos a partir de tiempos de espera de 65 segundos. Las pausas más cortas se ejecutan de forma ligera sin este paso adicional, lo cual es suficiente para la mayoría de los escenarios de límite de tasa con pausas de fracciones de segundo hasta unos pocos segundos.

¿Puedo usar Batch Interval y un nodo Wait a la vez en el mismo workflow?

Sí, incluso es un patrón habitual. El Batching en el nodo HTTP Request cubre el frenado continuo durante el procesamiento propiamente dicho, mientras que un nodo Wait adicional puede insertar en otro punto del workflow una pausa dirigida y más larga, por ejemplo entre solicitudes de página individuales durante la paginación o antes de un paso posterior especialmente limitado.

¿Qué hago si no conozco el límite de tasa exacto de una API?

Empieza de forma conservadora con un intervalo mayor, por ejemplo entre 1000 y 2000 milisegundos entre solicitudes, y observa si siguen apareciendo errores 429. Muchas APIs también indican el límite en las cabeceras de respuesta, que puedes evaluar en el nodo HTTP Request y usar para un ajuste dinámico del tiempo de espera. Además, tener activado Retry On Fail ayuda como red de seguridad si la estimación inicial fue demasiado ajustada.

¿Basta con Retry On Fail por sí solo para evitar límites de tasa con grandes volúmenes de datos?

No de forma fiable. Retry On Fail repite las solicitudes individuales fallidas, pero no impide que n8n envíe muchas solicitudes seguidas en un bucle grande sin batching. Con volumen alto, la combinación de Batching o Loop Over Items con un nodo Wait es la opción más robusta; Retry On Fail sigue siendo útil como refuerzo adicional.