HTTP Request dans n8n : retry, timeout et appels API fiables

Un workflow qui tourne parfaitement en test, puis échoue une nuit sur deux en production : dans la grande majorité des cas, le coupable est un appel API qui a échoué de façon transitoire — un pic de latence, un 503 passager, un rate limit atteint — et un node HTTP Request configuré avec ses réglages par défaut, c'est-à-dire sans retry ni timeout adapté. La bonne nouvelle, c'est que n8n embarque tout ce qu'il faut pour absorber ces échecs sans arrêter le workflow. Encore faut-il savoir quelles options activer, et surtout quelles erreurs retenter ou non.

Pourquoi les appels API échouent même quand tout est bien configuré

Un appel HTTP qui échoue n'est pas forcément le signe d'un bug. Trois familles d'échecs transitoires sont inévitables dès qu'on dépend d'un service distant :

• Le réseau : perte de paquets, coupure DNS momentanée, connexion réinitialisée. Rare pour une requête isolée, statistiquement certain sur des milliers d'exécutions.
• Le serveur distant : un 500 ou un 503 pendant un déploiement, une base de données saturée, un service tiers en incident. Vous n'y pouvez rien, mais dix secondes plus tard tout fonctionne à nouveau.
• La latence de queue : la requête aboutit, mais met trente secondes au lieu de trois cents millisecondes, parce qu'elle est tombée sur un serveur momentanément surchargé.

Ce dernier point est le plus contre-intuitif. Une étude de Google publiée dans Communications of the ACM (Dean & Barroso, 2013, « The Tail at Scale » — Google Scholar) montre que cette latence de queue est une propriété structurelle des systèmes distribués : même quand chaque composant est rapide en moyenne, une petite fraction des requêtes subit des délais extrêmes. Les auteurs plaident pour des techniques qui tolèrent cette variabilité — timeouts ajustés, requêtes de couverture — plutôt que d'espérer l'éliminer. Traduit pour n8n : dimensionner explicitement le timeout et les retries de chaque appel critique est la réponse normale à un comportement normal des API.

Retry On Fail : le réglage à connaître dans les settings du node

Le retry ne se configure pas dans les paramètres visibles du node HTTP Request, mais dans son onglet Settings (commun à la plupart des nodes n8n) :

• Retry On Fail : active la relance automatique en cas d'échec du node.
• Max Tries : le nombre total de tentatives avant que le node soit considéré en échec définitif.
• Wait Between Tries : le délai, en millisecondes, entre deux tentatives.

Avec Retry On Fail activé et un Wait Between Tries de quelques secondes, un 503 passager ou une micro-coupure réseau devient invisible : le node réessaie, réussit, et le workflow continue comme si de rien n'était. C'est le réglage qui, à lui seul, élimine la majorité des échecs nocturnes inexpliqués.

Deux limites à garder en tête :

• Le délai entre tentatives est fixe : n8n ne fait pas de backoff exponentiel natif à ce niveau. Pour des schémas de relance plus sophistiqués (attendre 2 s, puis 10 s, puis 60 s), il faut construire une boucle avec un node Wait — utile surtout face aux rate limits, comme détaillé dans notre article sur les erreurs 429 des API IA.
• Le retry relance tout le node : si celui-ci traite plusieurs items ou plusieurs pages d'une API (voir notre guide de la pagination avec HTTP Request), réfléchissez à ce qu'une relance complète implique.

Le timeout : arrêter d'attendre au bon moment

Le node HTTP Request propose une option Timeout (dans les Options du node) qui borne le temps d'attente d'une réponse. Sans timeout adapté, une requête qui traîne bloque l'exécution de longues minutes — et sur une instance chargée, plusieurs exécutions bloquées finissent par saturer la file, un sujet qui rejoint le passage en mode queue avec Redis.

Le bon réflexe : mesurer la latence normale de l'API appelée, puis fixer le timeout nettement au-dessus du cas courant mais bien en dessous de l'infini — par exemple 10 à 30 secondes pour une API classique, davantage pour une génération LLM longue. Combiné à Retry On Fail, un timeout court transforme une requête tombée sur un serveur lent en simple nouvelle tentative : plutôt réessayer vite que d'attendre indéfiniment une réponse qui ne viendra peut-être jamais.

Erreurs à retenter, erreurs à laisser échouer

Toute la subtilité d'une stratégie de retry tient dans cette distinction :

• À retenter — les échecs transitoires : 429 (rate limit : réessayer après une pause a du sens), 5xx (erreur côté serveur, souvent passagère), timeouts et erreurs réseau. Une nouvelle tentative a une vraie probabilité de succès.
• À ne PAS retenter — les échecs déterministes : 400 (votre requête est mal formée : elle le restera), 401 (credential invalide ou expiré), 404 (la ressource n'existe pas). Retenter cinq fois un 401 ne fait que retarder l'alerte et consommer du quota.

En pratique dans n8n : activez Retry On Fail pour absorber les transitoires, mais faites suivre le node d'une logique qui inspecte le code d'erreur quand toutes les tentatives ont échoué — un IF sur le status code qui route les 4xx vers une notification immédiate (« corrige ta requête ou ton credential ») et les 5xx persistants vers une file de reprise différée.

Le backoff, ou pourquoi retenter immédiatement aggrave le problème

Si une API répond 429 ou 503 parce qu'elle est saturée, la retenter immédiatement — depuis dix exécutions en parallèle — ajoute de la charge à un service déjà en difficulté : chaque client qui insiste rend le rétablissement plus lent pour tout le monde. D'où deux règles simples :

• Ne mettez jamais Wait Between Tries à une valeur quasi nulle : quelques secondes au minimum.
• Face à un rate limit récurrent, réduisez la cadence en amont (batching, node Wait entre les items) plutôt que d'empiler les retries — ce qui a aussi un effet direct sur la facture quand l'API est payante, comme le détaille notre guide pour suivre le coût des appels IA.

Idempotence : le risque caché du retry sur un POST

Un GET peut être rejoué sans conséquence. Un POST, non : si le serveur a traité la requête mais que la réponse s'est perdue (timeout, coupure réseau au mauvais moment), le retry crée un doublon — deuxième commande, deuxième ticket, deuxième email envoyé. Avant d'activer Retry On Fail sur un node qui écrit, posez-vous trois questions :

• L'API accepte-t-elle une clé d'idempotence (un identifiant unique par opération, que le serveur utilise pour dédupliquer) ? Si oui, envoyez-la systématiquement.
• Pouvez-vous dédupliquer côté n8n, en vérifiant l'existence de la ressource avant de la créer ?
• Le doublon est-il acceptable pour ce cas d'usage (une notification Slack en double est ennuyeuse, un paiement en double ne l'est pas) ?

Ces mécanismes sont exactement les mêmes que pour les webhooks entrants, détaillés dans notre article sur l'idempotence et la prévention des doublons.

Continue On Fail et branches d'erreur : router l'échec au lieu d'arrêter tout

Par défaut, un node en échec (après épuisement des retries) arrête l'exécution entière. Les settings du node permettent de changer ce comportement : au lieu de stopper le workflow, le node peut continuer et transmettre l'erreur — soit dans le flux normal, soit via une sortie d'erreur dédiée qui apparaît comme une seconde branche sur le node.

Cette branche d'erreur est précieuse dès qu'un workflow traite un lot d'items : un item sur cinquante qui échoue ne doit pas condamner les quarante-neuf autres. Le motif type : la branche principale poursuit le traitement des items réussis, la branche d'erreur enregistre les échecs (dans une base, un Google Sheet, une file de reprise) et notifie l'équipe. C'est le schéma qu'utilise notre workflow d'API question-réponse RAG pour renvoyer une réponse propre à l'appelant même quand un appel interne échoue.

L'Error Workflow global : le filet de sécurité final

Retry, timeout et branches d'erreur gèrent les échecs prévus. Pour tout le reste — le node auquel personne n'avait pensé, l'exécution qui plante sur un cas non couvert — n8n permet d'associer à chaque workflow un Error Workflow : un workflow séparé, déclenché automatiquement quand une exécution échoue, qui reçoit le contexte de l'erreur (workflow concerné, node en cause, message).

La bonne architecture : un seul Error Workflow global pour toute l'instance, qui notifie sur Slack ou par email avec le nom du workflow et le lien vers l'exécution échouée, référencé dans les settings de chaque workflow en production. Sa mise en place complète est détaillée dans notre guide de l'Error Workflow — c'est le complément indispensable, pas le remplaçant, des réglages au niveau du node.

Check-list avant la mise en production

• Retry On Fail activé sur chaque HTTP Request critique, avec un Wait Between Tries de quelques secondes.
• Timeout explicite, calibré sur la latence réelle de l'API (ni 5 secondes pour un LLM, ni 5 minutes pour un CRM).
• 4xx routés vers une alerte, pas vers un retry : un 401 se corrige, il ne se réessaie pas.
• Idempotence vérifiée avant tout retry sur un POST.
• Branche d'erreur sur les traitements par lot, Error Workflow global pour tout le reste.

Ces réglages prennent dix minutes par workflow et changent radicalement le comportement en production : les incidents transitoires s'absorbent seuls, les vraies erreurs remontent immédiatement avec leur contexte. Les workflows des packs FlowKit — dont le Pack Inbox IA (79 €), qui enchaîne les appels aux API email et IA — sont livrés avec ces réglages déjà en place ; il ne reste qu'à ajuster les seuils à vos API.