Cómo resolver errores de límite de solicitudes
Nota de alcance: reconstrucción editorial basada en la documentación oficial, capturada el 2026-05-16. Describe esa versión histórica; no acredita funciones, límites ni disponibilidad actuales. Consulta la fuente vigente antes de configurar un flujo nuevo.
RateLimitError indica que una aplicación ha recibido más solicitudes de las que admite en un periodo. Se relaciona con HTTP 429 Too Many Requests, aunque las aplicaciones externas no siempre clasifican sus errores del mismo modo. Identifica primero qué servicio impone el límite y qué conexiones o escenarios comparten esa cuota.
Escenarios instantáneos
La guía sitúa el control Maximum runs to start per minute en la programación del escenario, accesible desde el icono de rayo del disparador o desde Schedule settings. Su objetivo es distribuir las ejecuciones que llegan en ráfagas.
El número de ejecuciones no equivale al número de solicitudes: una sola ejecución puede llamar varias veces a la misma aplicación. Calcula el efecto de los módulos y paquetes procesados, no solo el del disparador.
Escenarios programados
Puedes aumentar el intervalo entre ejecuciones o reducir el campo Limit del módulo que recupera registros. Elige una combinación que permita vaciar la cola sin concentrar demasiadas llamadas.
Los números de ejemplo de la fuente no son límites universales. Consulta la cuota oficial de la aplicación antes de elegir la frecuencia y el tamaño de cada lote.
Reducir solicitudes en ambos casos
- Usa acciones por lotes, como añadir o actualizar varias filas, cuando la aplicación las ofrezca.
- Agrupa paquetes con un agregador si el módulo posterior admite una colección.
- Revisa otros escenarios que utilicen la misma aplicación: la carga compartida puede explicar un error que no aparece en una prueba aislada.
Procesamiento secuencial y pausas
El procesamiento secuencial —Process data in order en la ayuda actual— hace que el disparador trate los datos entrantes uno a uno, en el orden de llegada, y espera a que termine una ejecución antes de iniciar la siguiente. La captura del 2026-05-16 anotaba dos límites: puede detener el escenario ante un error y, si además hay ejecuciones incompletas guardadas, el escenario se pausa hasta procesarlas para conservar el orden. Consulta la sección Advanced strategies > Process data in order de la ayuda oficial sobre errores de límite para el comportamiento vigente.
Sleep introduce una espera antes de un módulo de hasta 300 segundos (5 minutos). Sirve para espaciar solicitudes repetidas, pero la propia guía advierte que suele retrasar el problema en lugar de resolverlo. Ajusta la espera según la cuota real de la aplicación; el detalle está en la sección Sleep module de la ayuda oficial.
Ejecuciones incompletas y reintentos
Con Store incomplete executions activado en Scenario settings, Make conserva la ejecución fallida para resolverla después. La captura del 2026-05-16 describía estas respuestas automáticas cuando no hay un manejador de errores propio:
| Tipo de escenario | Sin ejecuciones incompletas | Con ejecuciones incompletas |
|---|---|---|
| Programado | Pausa de 20 minutos antes de la siguiente ejecución, sin repetir la fallida | Pausa de 20 minutos y reintento de la ejecución incompleta con espera exponencial |
| Instantáneo | Reintento desde el inicio con espera exponencial | Reintento de la ejecución incompleta con espera exponencial |
La ayuda oficial mantiene este cuadro y enlaza la espera exponencial y las ejecuciones incompletas. Son respuestas automáticas, no una garantía de que el problema quede resuelto: comprueba el historial antes de repetir acciones y corrige los errores de mapeo en lugar de reintentarlos sin cambios.
Comprobar el resultado
Revisa el historial tras un lote representativo: solicitudes realizadas, paquetes pendientes y reintentos. Si el error persiste, reduce la concurrencia o el tamaño del lote y contrasta la cuota del proveedor. No provoques una avalancha de reintentos para verificar el límite.