Nœud Webhook n8nConfigurer Webhook dans n8n.

Par défaut, un webhook n'écoute qu'une méthode à la fois : GET ou POST, jamais les deux. Activer ce booléen dans les réglages du nœud lève la contrainte, et le nœud obtient une sortie par méthode pour aiguiller le workflow selon la façon dont il a été appelé.

• Allow Multiple HTTP Methods : désactivé au départ ; une fois actif, le nœud accepte GET et POST, les autres s'ajoutent dans le champ HTTP Method.
• HTTP Method : les méthodes écoutées, parmi DELETE, GET, HEAD, PATCH, POST, PUT.

C'est la fin de l'URL du webhook. n8n la remplit avec une suite de caractères aléatoire pour éviter toute collision entre deux nœuds, ce qui est prudent mais illisible à communiquer. Remplace-la par quelque chose de parlant dès que l'URL doit être saisie dans la configuration d'un tiers.

• Path : un champ texte, exemple webhook, qui accepte aussi des variables de route introduites par deux-points : /:variable, /path/:variable, /:variable/path, /:variable1/path/:variable2 ou /:variable1/:variable2. Dès qu'une valeur dynamique est utilisée, n8n préfixe le chemin par webhookId.

Rien n'empêche un inconnu d'appeler une URL de webhook ouverte. Ce sélecteur pose un contrôle devant le workflow, et un appel qui échoue au contrôle n'atteint jamais le premier nœud.

• Authentication : basicAuth pour un couple identifiant et mot de passe, headerAuth pour un secret partagé transmis dans l'en-tête de ton choix, jwtAuth pour les appelants qui envoient déjà un jeton signé, none pour une adresse publique.

Détermine à quel moment l'appelant reçoit sa réponse et ce qu'elle contient. C'est ce réglage qui sépare le simple récepteur du point d'entrée sur lequel l'appelant patiente vraiment.

• Respond : onReceived répond dès l'exécution du nœud, avec le message Workflow got started ; lastNode attend et renvoie les données du dernier nœud exécuté ; responseNode confie la réponse à un nœud Respond to Webhook placé plus loin.
• Response Data : avec lastNode, au choix allEntries pour un tableau, firstEntryJson pour un objet unique, firstEntryBinary pour un fichier, noData pour un corps vide.
• Property Name : requis avec firstEntryBinary, il nomme la propriété binaire renvoyée.

Les requêtes entrantes sont lues comme du JSON, sauf indication contraire. Cette bascule fait accepter un fichier dans la requête, ce qui devient indispensable le jour où un prestataire envoie un PDF plutôt qu'un lien vers ce PDF.

• Binary File : un booléen indiquant que le webhook va recevoir des données binaires. Il n'apparaît qu'avec les méthodes POST, PATCH ou PUT.

Un fichier reçu doit se ranger quelque part sur l'item pour que les nœuds suivants le retrouvent. C'est toute la fonction de cette option, et elle ne sert que si des données binaires arrivent réellement.

• Field Name for Binary Data : le nom du champ de sortie dans lequel le fichier reçu est écrit.

Colle une URL de webhook dans un outil de discussion et son générateur d'aperçu va la visiter aussitôt. Le workflow démarre, une exécution s'affiche, personne ne l'a demandée. Cette option écarte ces appelants avant que quoi que ce soit ne se déclenche.

• Ignore Bots : un booléen qui ignore les requêtes des robots du type générateurs d'aperçu de lien et robots d'indexation.

L'authentification contrôle un secret, celle-ci contrôle l'adresse. Le réglage prend tout son sens quand l'appelant est un serveur fixe et non un navigateur : la liste des origines légitimes est alors courte et connue d'avance.

• IP(s) Allowlist : une liste d'adresses ou de plages CIDR séparées par des virgules, exemple e.g. 127.0.0.1, 192.168.1.0/24. Vide, elle laisse passer toutes les adresses.

Certains appelants ne lisent qu'un code de statut, d'autres se plaignent d'un corps inattendu. Activer ce réglage envoie la réponse sans aucun corps.

• No Response Body : un booléen qui empêche n8n d'envoyer un corps de réponse. Il est disponible avec Respond réglé sur onReceived.

La réponse embarque par défaut tout le JSON de l'entrée. Désigner une propriété ici la réduit à cette seule valeur, ce qui arrange les appelants qui attendent une chaîne et non un objet.

• Property Name : le nom de la propriété dont la valeur est renvoyée à la place du JSON complet. Elle apparaît avec Respond sur lastNode et Response Data sur firstEntryJson.

Une fois ce réglage actif, le nœud conserve le corps tel qu'il est arrivé au lieu de l'analyser. Tout ce que l'analyse aurait remodelé, ou refusé, passe intact.

• Raw Body : un booléen indiquant que le nœud reçoit le corps en format brut, en binaire.

Une exécution réussie répond avec un code par défaut. On le remplace quand l'appelant lit le statut pour décider de la suite, ce qui arrive vite avec les prestataires qui relancent dès qu'un code les surprend.

• Response Code : au choix 200, 201, 204, 301, 302, 304, 400, 401, 403, 404, ou customCode.
• Code : le nombre renvoyé avec customCode, exemple e.g. 400.

Les réponses partent en application/json. Ce champ remplace cet en-tête quand l'appelant attend un autre format, et il ne modifie que le type annoncé, jamais les données elles-mêmes.

• Response Content-Type : un content-type personnalisé renvoyé à la place de application/json, exemple application/xml. Il apparaît avec Respond sur lastNode et Response Data sur firstEntryJson.

Plutôt que de renvoyer ce que le workflow a produit, ce réglage retourne une chaîne fixe. La réponse est décidée à la conception et ne dépend pas de l'exécution.

• Response Data : le texte personnalisé à envoyer, exemple success. Disponible avec Respond réglé sur onReceived.

Ajoute des en-têtes à ce que le nœud renvoie. Chaque entrée est un nom et une valeur, et rien n'empêche d'en empiler autant que l'appelant en réclame.

• Name : le nom de l'en-tête.
• Value : sa valeur, qui accepte une expression comme {{ $json.token }} quand elle doit venir du workflow.