Respuesta directa: un reintento seguro necesita identificar la misma operación y saber qué fallos son repetibles. Utiliza primero la idempotencia documentada de la API, conserva una clave estable y limita intentos y esperas. Activar Retry On Fail no evita por sí solo crear pedidos, cobros o mensajes duplicados.
Enlace de afiliación: hay un enlace asociado de n8n Cloud. FloxoLab puede recibir una comisión si contratas mediante él, sin coste adicional para ti. La secuencia siguiente es una guía de diseño: las garantías concretas dependen de la API y del almacenamiento utilizados.
Primero decide si puedes repetir la petición
Una lectura suele tener efectos distintos de una operación que crea un recurso. No presupongas que todos los métodos o puntos de acceso (endpoints) del mismo proveedor se comportan igual. Revisa su contrato de idempotencia, códigos de error y condiciones de repetición.
Un tiempo de espera agotado (timeout) no demuestra que la operación no se ejecutó. La API puede haber guardado el pedido y haberse perdido la respuesta. Si vuelves a enviar una creación sin la misma identidad, puedes obtener un segundo pedido. Para un resultado ambiguo, consulta el estado o usa la protección documentada antes de repetir a ciegas.
Crea una clave para una operación de negocio
La clave debe ser estable entre los intentos de la misma operación. Un identificador nuevo en cada ejecución identifica intentos, no el trabajo que quieres realizar una sola vez. Utiliza un ID de origen estable y un prefijo que indique la acción.
={{ 'create-order:' + $json.orderId }}Esta expresión ilustra una creación de pedido. Comprueba que orderId existe y que dos negocios distintos no comparten accidentalmente la misma identidad. Si cambia el contenido material de una operación, sigue las reglas del proveedor para reutilizar o generar una clave; no reutilices la misma para solicitudes diferentes sin revisar su contrato.
No registres secretos o información personal innecesaria dentro de la clave. Necesitas correlación, no incluir toda la ficha del cliente en una cabecera o un registro.
Usa primero la idempotencia de la API
Si el endpoint acepta una cabecera o campo de idempotencia, configura exactamente lo que documenta. No todos usan el mismo nombre, duración o tratamiento de errores. Guarda la clave antes del primer envío para que una recuperación posterior pueda reutilizarla.
Comprueba qué ocurre cuando llega la misma clave con el mismo contenido, con otro contenido y después del periodo de retención. Una garantía de deduplicación durante una ventana no es una garantía indefinida. Conserva el identificador remoto devuelto para poder consultar el recurso creado.
Configura reintentos limitados en n8n
Retry On Fail puede repetir la ejecución del nodo cuando falla, pero no entiende por sí mismo la semántica de un pago o una creación. Define un número máximo de intentos y una espera apropiada; prueba el comportamiento en una operación sin consecuencias antes de aplicarlo a producción.
| Respuesta o fallo | Comprobación |
|---|---|
| 400 por datos inválidos | Corregir entrada antes de repetir |
| 401 o 403 | Revisar autenticación o permisos |
| 429 | Respetar límites y la espera indicada por el proveedor |
| 5xx o timeout | Evaluar transitoriedad y posible operación ya realizada |
No clasifiques todo 500 como seguro para repetir ni todo error de red como una operación no recibida. La decisión depende del endpoint. Guarda suficiente evidencia para que quien atienda el fallo pueda distinguir una petición rechazada de un resultado desconocido.
Reduce la presión ante un 429
Reintentar inmediatamente muchas peticiones puede prolongar el límite. Si la API ofrece Retry-After u otra indicación, interpreta su formato y respétala. Cuando debas aplicar una política propia, utiliza espera creciente y un máximo; en sistemas concurrentes, una variación controlada puede evitar que todos vuelvan a la vez.
La política necesita un límite de tiempo total además de intentos. Un flujo que tarda demasiado puede crear una cola de trabajo ya obsoleto. Decide cuándo detenerlo, alertar y dejar el caso para revisión, en lugar de ocultar un bucle ilimitado detrás de un nodo Wait.
Control persistente de duplicados y concurrencia
Cuando la API no proporciona una garantía suficiente, registra la operación en almacenamiento persistente. Un patrón robusto utiliza una clave única y una transición atómica para reservar el trabajo. Un simple «buscar y después insertar» puede dejar pasar dos ejecuciones simultáneas.
Modela estados como pendiente, en proceso, completado y resultado ambiguo, con sus reglas de recuperación. Guarda identidad, intentos, fechas y referencia remota, sin acumular datos privados innecesarios. Una reserva bloqueada necesita un procedimiento explícito para revisión o expiración; no basta con borrarla y repetir.
La protección local y la operación remota no forman automáticamente una transacción única. Si el proceso se interrumpe después de crear el recurso remoto pero antes de marcar completado, tienes que reconciliar el resultado. La idempotencia del destino suele ser la protección más importante en esa ventana.
No uses datos estáticos como un bloqueo transaccional
Un dato guardado dentro de un flujo de trabajo no debe presentarse como un bloqueo de producción seguro entre ejecuciones concurrentes. Para operaciones importantes, utiliza un mecanismo que pueda imponer unicidad y actualizaciones atómicas en el almacenamiento que hayas elegido.
Lo mismo sucede con un nodo de eliminación de duplicados: puede servir en un contexto acotado, pero no sustituye sin más la garantía del servicio remoto o una reserva transaccional. Documenta exactamente qué duplicados impide y cuáles todavía pueden ocurrir.
Secuencia de una operación preparada para fallos
- Valida la entrada y obtén la identidad estable del evento.
- Comprueba o reserva atómicamente la operación en el registro persistente.
- Envía la petición con la clave de idempotencia cuando la API la admita.
- Ante éxito, guarda el ID remoto y marca completado.
- Ante fallo transitorio, aplica la espera y el límite definidos.
- Ante resultado ambiguo, consulta o reconcilia antes de crear otra operación.
- Al superar el límite, conserva evidencia y avisa al responsable.
Prueba por separado un evento duplicado, dos ejecuciones concurrentes, un 429 y una interrupción después del envío. El objetivo no es demostrar que «un flujo terminó», sino conocer qué ocurre en cada ventana de fallo.
Relaciona el reintento con el origen
Si el evento llega por webhook, el emisor también puede reintentar. Necesitas saber qué identificador conserva entre envíos y qué respuesta espera. La guía de webhooks ayuda a separar la recepción de los fallos posteriores.
En alojamiento propio, la persistencia y recuperación forman parte del diseño. Revisa qué conserva un reinicio y cómo recuperas la base de datos. La comparación de alojamiento explica esa responsabilidad. Si estás empezando, la introducción a n8n sitúa nodos, disparadores y propiedad del proceso.
Preguntas frecuentes
¿Retry On Fail evita duplicados?
No. Repite intentos; la prevención depende de la identidad, la API y los controles persistentes.
¿Debo repetir cualquier 500?
No sin comprobar el contrato y los efectos posibles. Puede haber un resultado remoto que todavía debas reconciliar.
¿Basta con revisar si el ID ya está en una hoja?
No como garantía frente a concurrencia. Dos ejecuciones pueden observar lo mismo antes de escribir; necesitas una reserva adecuada a la consecuencia.
Fuentes y límites
Revisado el 13 de noviembre de 2026: HTTP Request de n8n y problemas habituales. Las garantías de idempotencia se deben confirmar además en la documentación del endpoint concreto. No se ha probado aquí una API de pagos ni una ejecución real de cliente. Consultar n8n Cloud mediante el enlace asociado.