n8n estrena límites de API por clave en la versión 2.47.0

Un límite por clave de API resuelve un problema que ya costaba caro

n8n 2.47.0 introduce límites de velocidad para la API pública: los administradores definen cuántas peticiones puede hacer cada clave antes de que la instancia la frene. El objetivo es muy concreto: que un workflow descontrolado choque contra su propio límite en lugar de dejar sin servicio a los demás equipos de la misma instancia.

El problema es más común de lo que parece. Un nodo de n8n se ejecuta una vez por ítem, así que una lista de 1.000 ítems lanza alrededor de 1.000 peticiones de golpe. Si varias áreas comparten instancia, ese pico bloquea a todos sus equipos. La propia compañía reconoce que algunos clientes ya habían construido sus propios limitadores alrededor de n8n para protegerse de esa situación.

¿Por qué el límite de la API pública importa cuando varios equipos comparten una instancia?

Cuando varias áreas construyen sobre la misma instancia, la API pública pasa a ser una dependencia compartida. La consumen clientes de API hechos por distintos equipos, pero también los propios workflows que llaman a la API de su instancia a través del nodo de n8n o del nodo HTTP Request.

¿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 →

Ahí está el riesgo: automatizaciones que generan muchísimo tráfico en poco tiempo. Un workflow que recorre una lista larga de ítems se convierte, sin querer, en un bloqueo masivo para el resto del equipo.

Los límites imponen un techo por clave de API. Cada equipo conserva su espacio para construir y la instancia queda protegida frente a la automatización que se desboca.

¿Qué hace exactamente el nuevo control de rate limits en n8n?

Cuatro características definen su comportamiento:

Lecturas y escrituras con límites separados. Se configuran de forma global y por endpoint, con la opción de fijar un tope más estricto en las escrituras. Cada clave de API lleva su propio conteo dentro de esos límites.
Señal clara al cliente. Al superar el límite, n8n responde con un 429 que incluye las cabeceras Retry-After y de rate limit, de modo que el cliente sabe cuándo reintentar y cuántas peticiones le quedan por delante.
Valores por defecto y cambios en caliente. Cada límite arranca con un valor por defecto, y los ajustes hechos desde la página de configuración o desde la API se aplican de inmediato, sin reiniciar el servicio.
Coherencia en despliegues multi-main. En configuraciones con varios nodos main, todos comparten un único contador por clave de API mediante Redis, así que una clave que se pasó del límite recibe 429 en todos ellos hasta que termina la ventana.

¿Cómo se activan los límites de la API pública en n8n?

El rate limiting viene desactivado por defecto, así que tú decides cuándo encenderlo. Hay tres caminos según cómo ejecutes n8n:

Página de configuración: ve a Settings > Policies > Public API Limits, activa «Enable API key rate limits», ajusta los límites y las ventanas, y selecciona «Enable limits».
API pública: usa GET /api/v1/settings/rate-limits para leer la configuración actual y PUT /api/v1/settings/rate-limits para reemplazarla. La clave de API necesita el scope securitySettings:manage.
Variables de entorno (self-hosted): define N8N_PUBLIC_API_RATE_LIMIT_ENABLED en true y reinicia n8n; después usa las variables N8N_PUBLIC_API_RATE_LIMIT_* para cambiar límites y ventanas concretas.

Conviene entender la jerarquía: los cambios desde la interfaz o la API se aplican al instante, sin reinicio. Pero una variable de entorno manda por encima de ambos y el campo correspondiente aparece bloqueado en la interfaz, así que el valor queda fijo hasta que modifiques la variable y reinicies n8n.

¿Qué hacer para que tus workflows no choquen con el 429?

Esta es la parte que más te va a servir en el día a día. Para los clientes de API, n8n recomienda cuatro hábitos:

Esperar los segundos que indique Retry-After antes de reintentar.
Añadir un retraso aleatorio de hasta 5 segundos, para que los reintentos de distintos clientes se repartan.
Vigilar X-RateLimit-Remaining y bajar el ritmo cuando se acerque a 0, hasta el momento que marque X-RateLimit-Reset.
Repartir los trabajos grandes en la ventana, enviando peticiones a un ritmo estable en lugar de concentrarlas.

Los workflows que llaman a la API de su propia instancia necesitan un paso extra. El nodo de n8n y el nodo HTTP Request envían una petición por ítem y fallan ante un 429, así que hay que añadir Batching al nodo (en Request Options para el nodo de n8n y en Options para el HTTP Request) y definir Items per Batch y Batch Interval (ms). La referencia que da la documentación es clara: cinco ítems por segundo equivalen a 300 peticiones por minuto, por debajo de todos los límites por defecto.

Batching funciona mejor aquí que Retry On Fail, que espera como máximo 5 segundos entre intentos y suele reintentar dentro de la misma ventana, justo cuando el contador todavía no se reinició.

¿Necesitas dar más margen a una integración concreta?

Todas las claves de una instancia comparten los mismos límites. Cada una lleva su propio conteo, pero el techo es común, así que no existe una forma de darle a una integración un cupo mayor que al resto. La salida que indica n8n es mover esa integración a una instancia separada.

Hay otros detalles operativos que conviene tener a mano antes de tocar la configuración:

Si cambias un límite mientras hay peticiones en curso, el nuevo valor aplica de inmediato. Si es más bajo que el conteo actual de una clave, su siguiente petición recibe 429 y el contador se reinicia al terminar la ventana.
Para desactivar un tipo de límite, se pone en 0: puedes apagar lecturas o escrituras, de forma global o por endpoint, y mantener el resto. Con el rate limiting activo, al menos un límite debe ser mayor que 0.
Solo cuentan las peticiones con clave de API que van a /api/v1. Las peticiones que salen del editor de n8n no consumen cupo.

Claves de idempotencia: reintentar sin duplicar datos

Si vas a reintentar después de un 429, aparece un riesgo clásico: un POST que en realidad sí se ejecutó y que vuelve a correr, generando un registro duplicado. Las idempotency keys, disponibles desde n8n 2.45.0, resuelven exactamente eso.

El mecanismo es simple: envías la cabecera Idempotency-Key en un POST de la API pública. Si la petición sale bien, n8n guarda la respuesta durante 12 horas y un reintento con la misma clave y el mismo cuerpo recibe esa respuesta almacenada en lugar de ejecutar el POST otra vez. Si la primera petición falla, n8n libera la clave y el reintento corre con normalidad.

¿Qué significa esto para tu startup?

Que n8n esté añadiendo gobernanza de tráfico no es un detalle cosmético. Es la señal de que la herramienta dejó de ser el juguete de automatización de un solo equipo y pasó a sostener operaciones críticas de varias áreas al mismo tiempo.

El contexto ayuda a dimensionarlo. n8n nació en Berlín en 2019, fundada por Jan Oberhauser, y se posicionó como alternativa self-hostable a Zapier y Make. Según el perfil de la compañía que publica Startuprad.io, n8n cerró una Serie C de US$180M en octubre de 2025 liderada por Accel a una valoración de US$2.500M, y en mayo de 2026 recibió una inversión estratégica de SAP a una valoración reportada de US$5.200M. El mismo perfil menciona, citando un comunicado de la empresa, más de 1.400 clientes enterprise y 1,7 millones de desarrolladores activos mensuales: cifras reportadas por la compañía y no verificadas de forma independiente.

Cuando una plataforma llega a ese tamaño, los problemas de convivencia dentro de una misma instancia dejan de ser anécdotas y se convierten en tickets de soporte recurrentes. Por eso funciones como esta importan más de lo que sugiere su nombre técnico.

Acciones concretas para esta semana:

Audita qué workflows llaman a la API de tu propia instancia. Si encuentras nodos que procesan listas largas (sincronizaciones de CRM, envíos masivos, migraciones de datos), son los candidatos número uno a disparar un pico de tráfico.
Activa Batching en esos nodos antes de encender los límites. Ajusta Items per Batch y Batch Interval a un ritmo conservador (los cinco ítems por segundo que da n8n como referencia sirven de punto de partida) y mide. Así el 429 aparece cuando ya tienes margen para reaccionar.
Fija primero los límites de escritura. Son los que más daño pueden causar si se descontrolan, y puedes dejar las lecturas más holgadas sin perder protección.
Añade Idempotency-Key a todos tus POST. Es la diferencia entre reintentar con confianza y arriesgarte a duplicar datos en producción.
Documenta los límites para todos los equipos. Un límite que nadie conoce se convierte en un incidente a las 3 de la mañana.

Conclusión

El rate limiting de la API pública llegó con n8n 2.47.0 en todos los planes, tanto en n8n Cloud como en instalaciones self-hosted, y trabaja en conjunto con las idempotency keys de n8n 2.45.0. Para un equipo pequeño que recién arranca puede parecer configuración avanzada; para cualquier empresa con dos o más áreas construyendo sobre la misma instancia, es la diferencia entre un incidente acotado y una tarde entera de automatizaciones caídas. Actívalo con límites conservadores y enséñale a tus workflows a pedir permiso antes de golpear la puerta.