Node Respond to Webhook n8n : maîtriser les réponses HTTP de vos workflows

Par défaut, un node Webhook n8n répond tout seul : soit immédiatement avec un accusé de réception générique, soit à la fin du workflow avec la sortie du dernier node. C'est suffisant pour recevoir des notifications, mais dès que l'appelant attend une vraie réponse — un JSON structuré, un code 400 en cas de données invalides, une redirection, un fichier — il faut reprendre la main. C'est exactement le rôle du node Respond to Webhook : décider quoi renvoyer, quand le renvoyer, avec quel code HTTP et quels en-têtes. Ce guide couvre sa configuration complète, les types de réponses disponibles, les patterns qui en tirent le meilleur parti (réponse anticipée, branchement 200/400, mini-API REST) et les pièges à connaître.

Les trois modes de réponse du node Webhook

Tout part du paramètre Respond du node Webhook, qui propose trois comportements :

• Immediately : n8n répond dès réception de la requête, avec un message de confirmation standard, puis exécute le workflow. L'appelant ne saura jamais si le traitement a réussi.
• When Last Node Finishes : n8n attend la fin du workflow et renvoie les données du dernier node exécuté. Pratique pour un cas simple, mais aucun contrôle sur le code HTTP, la forme exacte de la réponse ou la branche qui répond.
• Using 'Respond to Webhook' Node : n8n garde la connexion HTTP ouverte et ne répond que lorsqu'un node Respond to Webhook est atteint. C'est le seul mode qui donne un contrôle total.

Ce troisième réglage est indispensable : sans lui, le node Respond to Webhook présent dans le workflow est tout simplement ignoré. Si les bases du node Webhook (méthodes HTTP, URL de test et de production, authentification) ne sont pas encore en place, commencez par notre guide complet du webhook n8n.

Mise en place pas à pas

1. Ajoutez un node Webhook, choisissez la méthode HTTP (POST pour recevoir des données, GET pour une consultation) et réglez Respond sur Using 'Respond to Webhook' Node.
2. Construisez votre traitement : validation, appel d'API, requête en base, agent IA.
3. Ajoutez un node Respond to Webhook à l'endroit où la réponse doit partir — pas forcément à la fin du workflow, on y revient plus bas.
4. Choisissez le type de réponse dans Respond With, puis ajustez le code HTTP et les en-têtes dans les options du node.
5. Testez avec l'URL de test, puis activez le workflow pour basculer sur l'URL de production. Pour tester depuis un service externe alors que votre instance tourne sur votre machine, voyez notre article sur tester ses webhooks n8n en local.

Les types de réponses disponibles

Le paramètre Respond With du node détermine ce que reçoit l'appelant :

• JSON : vous rédigez le corps de la réponse vous-même, avec des expressions n8n à l'intérieur. Le format le plus courant pour une API.
• First Incoming Item / All Incoming Items : renvoie directement le ou les items reçus par le node, sans reformatage — rapide pour exposer le résultat d'un traitement tel quel.
• Text : une chaîne brute, utile pour les intégrations qui attendent un simple OK ou un contenu HTML minimal.
• Binary : renvoie un fichier présent dans les données binaires de l'item — PDF généré, image, export CSV.
• Redirect : renvoie une redirection HTTP vers l'URL de votre choix, par exemple une page de remerciement après soumission d'un formulaire.
• No Data : un corps vide, quand seul le code HTTP compte (un 204 après une suppression, un 202 pour un traitement accepté).

Exemple de corps JSON pour un endpoint de validation :

{
  "status": "ok",
  "lead_id": "{{ $json.id }}",
  "score": {{ $json.score }},
  "message": "Demande enregistrée, réponse sous 24h."
}

Code HTTP et en-têtes personnalisés

Dans les options du node, Response Code remplace le 200 par défaut (201 pour une création, 400 pour une entrée invalide, 404 pour une ressource introuvable…), et Response Headers ajoute des en-têtes arbitraires : Content-Type pour un binaire, Cache-Control, ou un en-tête maison comme X-Request-Id pour faciliter le suivi côté client. Un code et un corps d'erreur explicites valent toujours mieux qu'un 200 générique qui masque un échec.

Pattern n°1 : répondre tôt, traiter ensuite

Le node Respond to Webhook n'a pas besoin d'être le dernier du workflow. Placé juste après la réception et une validation rapide, il acquitte la requête en quelques centaines de millisecondes, puis le workflow continue de s'exécuter derrière : enrichissement, appel à un LLM, écritures en base.

C'est le pattern indispensable face aux services qui imposent un délai de réponse court : Stripe considère un webhook en échec et le renvoie si la réponse tarde, Slack attend un acquittement en moins de 3 secondes pour ses interactions. Dès qu'un agent IA ou une chaîne d'appels d'API entre dans le traitement, la réponse synchrone devient intenable — notre article sur les timeouts de webhook avec un agent IA détaille ce scénario. Et comme un fournisseur qui n'a pas reçu de réponse à temps renvoie souvent le même événement, combinez ce pattern avec une logique d'idempotence pour éviter les doublons.

Ce réflexe de l'acquittement rapide ne vise pas que les machines : une étude de Fiona Fui-Hoon Nah publiée en 2004 dans Behaviour & Information Technology, « A study on tolerable waiting time: how long are Web users willing to wait? », situe le temps d'attente tolérable d'un utilisateur web autour de 2 secondes pour une récupération d'information, un seuil que le retour d'information (feedback) permet d'étendre. Autrement dit, si votre webhook sert un formulaire ou un widget, répondre vite avec un message de confirmation, puis traiter en arrière-plan, correspond exactement à ce que la recherche sur la perception de l'attente recommande.

Pattern n°2 : plusieurs Respond to Webhook derrière un IF

Un endpoint sérieux ne renvoie pas 200 quand les données sont invalides. La structure type d'un endpoint de validation de formulaire :

1. Webhook (POST, Respond sur « Using 'Respond to Webhook' Node »).
2. IF : l'email est-il présent et bien formé ? Les champs obligatoires sont-ils remplis ?
3. Branche false → Respond to Webhook avec Response Code 400 et un JSON { "error": "invalid_email" }.
4. Branche true → traitement (CRM, notification, scoring) → Respond to Webhook avec un 200 et le résultat.

Chaque branche a son propre node de réponse, avec son code et son corps. Ce pattern s'applique tel quel derrière un Form Trigger multi-étapes remplacé par un webhook, ou pour valider les soumissions d'un formulaire maison hébergé sur votre site. Point essentiel : chaque chemin possible doit aboutir à un Respond to Webhook, sinon l'appelant attend dans le vide (voir les pièges plus bas).

Pattern n°3 : une mini-API REST avec n8n

En combinant plusieurs nodes Webhook (un par route et par méthode) et des réponses structurées, n8n devient un backend d'API léger :

• GET /webhook/leads → requête en base → Respond to Webhook (JSON, 200) ;
• POST /webhook/leads → validation → insertion → Respond to Webhook (201 avec l'ID créé, ou 400) ;
• POST /webhook/chat → appel LLM avec contexte → Respond to Webhook (JSON avec la réponse du modèle).

Ce dernier cas est exactement l'architecture d'un widget de chat IA intégré à un site web : le widget envoie la question au webhook, n8n interroge le modèle (éventuellement avec du RAG), et le Respond to Webhook renvoie la réponse en JSON que le widget affiche. Le workflow gratuit API question-réponse RAG implémente ce pattern de bout en bout, prêt à importer. Notez la distinction avec l'API REST native de n8n : celle-ci pilote n8n lui-même (workflows, exécutions, credentials), tandis que vos webhooks exposent vos propres endpoints métier.

Un endpoint exposé publiquement doit être protégé : authentification par en-tête, vérification de signature, filtrage IP — les options sont détaillées dans notre guide pour sécuriser un webhook n8n.

Pièges et limites à connaître

• Un seul Respond to Webhook exécuté par exécution. Le premier node atteint envoie la réponse et clôt la connexion HTTP ; si le flux en croise un second, il n'a plus personne à qui répondre. Concevez vos branches pour qu'une exécution ne traverse qu'un seul node de réponse.
• Timeout si aucun Respond n'est atteint. Une branche qui se termine sans node de réponse (un IF dont un chemin reste vide, une erreur qui interrompt le flux avant la réponse) laisse l'appelant en attente jusqu'au timeout. Vérifiez chaque chemin, cas d'erreur compris.
• Le mode du Webhook prime. Un Respond to Webhook dans un workflow dont le Webhook est resté sur « Immediately » ou « When Last Node Finishes » est ignoré — c'est la première chose à vérifier quand « le node ne fait rien ».
• Pas de streaming. Le node envoie une réponse complète en une fois : impossible de streamer la sortie d'un LLM token par token à travers lui. Pour un chat, soit vous acceptez la réponse d'un bloc, soit vous répondez tôt et livrez le résultat par un autre canal.
• Une seule réponse par requête. Impossible de « compléter » une réponse déjà envoyée : pour informer l'appelant de la suite d'un traitement asynchrone, prévoyez un callback vers une URL qu'il fournit, ou un endpoint de consultation du statut.

En résumé

Le node Respond to Webhook transforme un webhook n8n passif en véritable endpoint HTTP : il exige de régler le node Webhook sur « Using 'Respond to Webhook' Node », offre six types de réponses (JSON, items entrants, texte, binaire, redirection, corps vide), et laisse la main sur le code HTTP et les en-têtes. Les trois patterns à retenir : répondre tôt puis continuer le traitement pour respecter les délais de Stripe ou Slack, brancher plusieurs nodes de réponse derrière un IF pour des 200/400 propres, et assembler plusieurs webhooks en mini-API REST. Les deux règles d'or : un seul node de réponse exécuté par exécution, et aucun chemin du workflow qui se termine sans réponse. Pour voir le pattern API complet en action, le workflow gratuit API question-réponse RAG est prêt à importer.