API rate limit exceeded en n8n: corrige los 429 sin escrituras duplicadas
Corrige el error API rate limit exceeded en n8n: lee el 429, agrupa peticiones, reintenta tras la ventana del límite y usa claves de idempotencia.
Comprobado con las fuentes citadas el .
Requisitos previos y objetivo
Un error "API rate limit exceeded" significa que el servicio al que llamas quiere que envíes menos peticiones. En n8n puede aparecer como una respuesta HTTP 429 de un nodo HTTP Request. En este tutorial construirás un flujo de trabajo que gestiona esos 429 y no envía dos veces la misma escritura cuando reintenta.
Antes de empezar, ten esto preparado:
Sources: Handle rate limits | Nodes | n8n Docs, 429 Too Many Requests - HTTP | MDN
Paso a paso: gestiona los errores API rate limit exceeded
Sigue los pasos en orden. Después de cada uno, vuelve a ejecutar el flujo y comprueba el resultado antes de añadir el siguiente cambio. Así sabrás qué cambio marcó la diferencia.
Corrige los 429 paso a paso
- Reproducir: Provoca el 429 y lee el error en el panel de salida del nodo.
- Inspeccionar: Devuelve el código de estado y las cabeceras, y busca Retry-After.
- Agrupar: Ajusta Items per Batch y Batch Interval a los límites de la API.
- Reintentar: Activa Retry On Fail con una espera mayor que la ventana del límite.
- Proteger escrituras: Añade una clave de idempotencia a las peticiones POST si la API la admite.
Primero, reproduce el error API rate limit exceeded. Según la documentación de n8n, cuando un servicio devuelve el error 429, el nodo falla con un mensaje que indica que el servicio está recibiendo demasiadas peticiones. Puedes leer ese mensaje en el panel de salida del nodo.
Después, activa la opción de respuesta Include Response Headers and Status del nodo HTTP Request. La documentación de n8n indica que devuelve el código de estado y las cabeceras junto con el cuerpo. MDN explica que una respuesta 429 puede incluir una cabecera Retry-After que indica al cliente cuánto esperar. Sin embargo, esa cabecera es opcional y cada servidor fija sus propias reglas. La documentación de n8n no explica cómo actuar automáticamente según Retry-After, así que, por ahora, trátala como información que lees tú mismo.
Luego, espacia tus peticiones. En la opción Batching del nodo HTTP Request, Items per Batch define cuántos elementos se envían juntos y Batch Interval define la espera entre lotes en milisegundos. Elige valores que respeten los límites que documenta la API.
A continuación, abre la configuración (Settings) del nodo y activa Retry On Fail. La documentación de n8n recomienda que Wait Between Tries sea más largo que la ventana del límite de peticiones. Esa documentación no indica un número máximo de intentos ni esperas exponenciales.
Sources: Handle rate limits | Nodes | n8n Docs, HTTP Request | Nodes | n8n Docs, 429 Too Many Requests - HTTP | MDN
Protege las escrituras reintentadas con claves de idempotencia
Por último, protege tus escrituras. En la API de Stripe, todas las peticiones POST aceptan claves de idempotencia. Repetir una petición con la misma clave devuelve el primer resultado guardado en lugar de ejecutar de nuevo la operación. Este comportamiento es específico de Stripe. Nuestra sugerencia editorial: envía la clave como indique tu API, y solo si documenta que admite claves de idempotencia. Constrúyela a partir de un ID de negocio estable, como un número de pedido, y no de un valor aleatorio que cambie en cada reintento.
Sources: Idempotent requests | Stripe API Reference
Resultados esperados y solución de problemas
Una vez configurados los lotes y los reintentos, deberías ver menos errores 429. Si el error API rate limit exceeded sigue apareciendo, los reintentos con una espera mayor que la ventana del límite dan a un intento posterior la oportunidad de funcionar, pero un 429 aún puede detener el nodo si el límite persiste. Si algo sigue fallando, busca el síntoma a continuación.
| Síntoma | Causa probable | Qué revisar |
|---|---|---|
| Los 429 continúan | Los lotes son demasiado grandes o están demasiado juntos | Reduce Items per Batch o aumenta Batch Interval |
| Los 429 continúan tras los reintentos | Wait Between Tries es más corto que la ventana | Pon una espera mayor que la ventana del límite |
| Registros duplicados | Las peticiones POST reintentadas no tienen clave de idempotencia | Comprueba si la API admite claves de idempotencia |
| Duplicados incluso con clave | La clave cambia en cada reintento | Construye la clave a partir de un ID de negocio estable |
Si los reintentos se disparan siempre en el mismo momento, revisa una recomendación general más antigua. En una publicación de 2017 en su blog de ingeniería, Stripe recomendaba el backoff exponencial, en el que la espera se duplica tras cada fallo, más un jitter aleatorio para que muchos clientes no reintenten a la vez. Esa publicación tiene varios años y nada de esto es una función integrada de n8n. Cualquier versión en n8n es un patrón que diseñas tú.
Sources: Handle rate limits | Nodes | n8n Docs, HTTP Request | Nodes | n8n Docs, Idempotent requests | Stripe API Reference, Designing robust and predictable APIs with idempotency
