Là où le canal webhook entrant reçoit des événements externes pour les traiter, le nœud webhook_action fait l'inverse : il émet une requête HTTP vers vos systèmes depuis n'importe quel point d'un pipeline — l'équivalent des modules « HTTP » de Make ou « Webhooks » de Zapier.
Pourquoi
Vous avez probablement déjà :
- Un système d'alerting (PagerDuty, Opsgenie, Slack).
- Un outil ITSM (Jira, ServiceNow) pour gérer les tickets.
- Un dashboard custom qui agrège votre état opérationnel.
Plutôt que de demander à ces systèmes de poller betool, faites-les notifier par vos pipelines : placez un nœud webhook_action au point du graphe où l'événement se produit (un email qualifié, un filtre franchi, un rapport planifié…). Combiné au canal Planification, c'est aussi la base d'un push récurrent vers vos systèmes.
Configuration du nœud
| Champ | Rôle |
|---|---|
url | URL cible (templatable) |
method | GET / POST (défaut) / PUT / PATCH / DELETE |
headers / query | Dictionnaires {nom: template} |
body_mode | none / json (défaut) / form / raw / mapper / multipart |
body_template | Template du body (modes json / form / raw) |
mapping_spec | Construction du body via le payload mapper (recommandé) — profondeur, tableaux, transformations |
auth_mode | none (défaut) / bearer / basic / api_key_header / oauth2 (client credentials) |
auth_config | Paramètres du mode d'auth : {token}, {user, password}, {header, value} ou {credential_id} |
timeout_ms | Défaut 30 000 ms |
retry_count | Nombre de réessais (défaut 0, maximum 10), backoff exponentiel |
accepted_statuses | Codes HTTP considérés comme succès (défaut : 200, 201, 202, 204) |
output_key | Clé du flux où écrire la réponse (défaut webhook.response) |
Templating
URL, headers, query et body interpolent les clés du flux avec la syntaxe {chemin} :
{
"event": "order_qualified",
"order_id": "{webhook.payload.order_id}",
"verdict": "{exchange.result}"
}
Authentification
- Les credentials des modes
bearer/basic/api_key_header(le token, le mot de passe, la valeur de l'en-tête) sont stockés dans la configuration du nœud, mais ne ressortent jamais en clair : l'éditeur, l'API d'administration, les outils MCP et les propositions ne montrent qu'un marqueur « secret enregistré ». Dans l'éditeur, le champ affiche « •••••• enregistré — saisir pour remplacer » : laissez-le vide pour conserver le secret, saisissez une valeur pour le remplacer, ou cliquez sur Retirer pour l'effacer. L'identifiant (user) et le nom de l'en-tête (header) restent lisibles. - Copier-coller ou dupliquer un nœud ne recopie pas ses secrets : ressaisissez-les sur la copie.
- En mode
oauth2(client credentials), le nœud ne porte qu'une référence de credential ; le secret vit dans le stockage OAuth de l'organisation, n'est jamais renvoyé en lecture, et le token est obtenu (puis rafraîchi) à l'exécution. Le même credential sert à plusieurs nœuds, et une rotation du secret ne demande de rééditer aucun pipeline.
Envoi de fichiers (multipart)
Le mode multipart (RFC 7578) envoie champs texte et pièces jointes dans la même requête — pour les partenaires qui n'acceptent que multipart/form-data. Les fichiers sont référencés par leur clé d'object store et relus au moment de l'envoi (20 fichiers et 25 Mo au maximum) ; une clé hors du périmètre de votre organisation est refusée, et un envoi dont une pièce jointe manque est abandonné plutôt qu'émis amputé.
Retries & erreurs
- Un status hors
accepted_statuses, un timeout ou une erreur réseau déclenche un réessai avec backoff exponentiel (0,5 s, 1 s, 2 s, 4 s…), jusqu'àretry_countréessais. - La réponse (
status,headers,body) est écrite sousoutput_key, avec une cléerroraprès épuisement des réessais : les nœuds aval peuvent lire le résultat et déclencher un traitement de secours en cas d'échec. Le résultat est visible dans l'historique. - Pas de double envoi : si l'exécution est rejouée (reprise après un redéploiement, réessai de la file), un appel déjà accepté par votre système n'est pas réémis.
Prouver l'origine côté récepteur
Les requêtes de webhook_action portent l'authentification que vous configurez (auth_mode) : c'est elle qui prouve l'origine auprès de votre système. Pour le sens inverse — vérifier la signature de ce que betool reçoit — voir Webhook entrant.