Comprendre les événements répétés
Un webhook peut être relivré après un timeout. Une tâche planifiée peut aussi reprendre des données déjà traitées si son état n’a pas été conservé.
L’identifiant d’exécution n8n est utile au diagnostic, mais ne remplace pas l’ID métier d’une facture, d’une commande ou d’un message.
Concevoir des actions idempotentes
Avant une création, contrôlez la référence dans la destination ou utilisez la clé d’idempotence prévue par son API. Si deux exécutions concurrentes sont possibles, une simple recherche préalable ne garantit pas l’unicité.
Privilégiez une contrainte de base ou une opération atomique adaptée lorsque l’intégrité le nécessite.
Traiter les timeouts avec prudence
Après un délai dépassé, une API peut avoir exécuté la demande sans renvoyer la confirmation. Marquez l’opération « à vérifier », interrogez la destination et décidez de la reprise ensuite.
Les retries génériques sont adaptés aux lectures sûres ; l’envoi d’un email, d’une commande ou d’un paiement demande un contrôle supplémentaire.
Alerter et tester les cas limites
Journalisez la référence métier, l’étape défaillante et le statut de réconciliation. Envoyez une alerte exploitable sans inclure inutilement les données personnelles.
Testez une double livraison de webhook, une erreur 429, une réponse 500 et une perte de réponse après écriture réussie.
Automatisation des processus métier
Nous identifions les tâches répétitives, puis mettons en place des workflows reliés aux outils que vos équipes utilisent déjà.
Découvrir le serviceQuestions fréquentes
Retry On Fail peut-il créer un doublon ?
Oui, quand l’action distante a réussi avant l’erreur et n’est pas idempotente.
Faut-il simplement ignorer tous les webhooks déjà vus ?
Non : définissez l’état métier attendu et réconciliez les opérations incomplètes.
Que faire sans clé d’idempotence fournie par l’API ?
Utilisez une référence métier et un stockage avec contrôle d’unicité adapté au risque.