Appeler vos systèmes externes depuis un pipeline — le nœud webhook_action, templating, authentification, retries.

Webhooks sortants

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 sont stockés dans la configuration du nœud : ils restent visibles des membres qui peuvent ouvrir ce pipeline.
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. C'est le mode à préférer pour un secret sensible.

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_count réessais.
La réponse (status, headers, body) est écrite sous output_key, avec une clé error aprè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.