Llamar a tus sistemas externos desde un pipeline — el nodo webhook_action, plantillas, autenticación, reintentos.

Webhooks salientes

Donde el canal de webhook entrante recibe eventos externos para procesarlos, el nodo webhook_action hace lo contrario: emite una petición HTTP hacia tus sistemas desde cualquier punto de un pipeline — el equivalente de los módulos «HTTP» de Make o «Webhooks» de Zapier.

Por qué

Probablemente ya tienes:

Un sistema de alertas (PagerDuty, Opsgenie, Slack).
Una herramienta ITSM (Jira, ServiceNow) para gestionar los tickets.
Un dashboard personalizado que agrega tu estado operativo.

En lugar de pedir a esos sistemas que hagan polling a betool, haz que tus pipelines les notifiquen: coloca un nodo webhook_action en el punto del grafo donde se produce el evento (un correo cualificado, un filtro superado, un informe programado…). Combinado con el canal Planificación, también es la base de un envío recurrente hacia tus sistemas.

Configuración del nodo

Campo	Función
`url`	URL de destino (admite plantillas)
`method`	`GET` / `POST` (por defecto) / `PUT` / `PATCH` / `DELETE`
`headers` / `query`	Diccionarios `{nombre: plantilla}`
`body_mode`	`none` / `json` (por defecto) / `form` / `raw` / `mapper` / `multipart`
`body_template`	Plantilla del body (modos `json` / `form` / `raw`)
`mapping_spec`	Construcción del body mediante el payload mapper (recomendado) — profundidad, arrays, transformaciones
`auth_mode`	`none` (por defecto) / `bearer` / `basic` / `api_key_header` / `oauth2` (client credentials)
`auth_config`	Parámetros del modo de autenticación: `{token}`, `{user, password}`, `{header, value}` o `{credential_id}`
`timeout_ms`	Por defecto 30 000 ms
`retry_count`	Número de reintentos (por defecto 0, máximo 10), backoff exponencial
`accepted_statuses`	Códigos HTTP considerados como éxito (por defecto: 200, 201, 202, 204)
`output_key`	Clave del flujo donde escribir la respuesta (por defecto `webhook.response`)

Plantillas

URL, headers, query y body interpolan las claves del flujo con la sintaxis {ruta}:

{
  "event": "order_qualified",
  "order_id": "{webhook.payload.order_id}",
  "verdict": "{exchange.result}"
}

Autenticación

Las credenciales de los modos bearer / basic / api_key_header se almacenan en la configuración del nodo: siguen siendo visibles para los miembros que pueden abrir ese pipeline.
En modo oauth2 (client credentials), el nodo solo lleva una referencia de credencial; el secreto vive en el almacenamiento OAuth de la organización, nunca se devuelve en lectura, y el token se obtiene (y se refresca) en la ejecución. Es el modo preferible para un secreto sensible.

Envío de archivos (multipart)

El modo multipart (RFC 7578) envía campos de texto y adjuntos en la misma petición — para los socios que solo aceptan multipart/form-data. Los archivos se referencian por su clave de object store y se releen en el momento del envío (20 archivos y 25 MB como máximo); una clave fuera del perímetro de tu organización se rechaza, y un envío al que le falta un adjunto se abandona en lugar de emitirse incompleto.

Reintentos y errores

Un status fuera de accepted_statuses, un timeout o un error de red dispara un reintento con backoff exponencial (0,5 s, 1 s, 2 s, 4 s…), hasta retry_count reintentos.
La respuesta (status, headers, body) se escribe bajo output_key, con una clave error una vez agotados los reintentos: los nodos aguas abajo pueden leer el resultado y disparar un tratamiento de respaldo en caso de fallo. El resultado es visible en el historial.
Sin doble envío: si la ejecución se repite (reanudación tras un redespliegue, reintento de la cola), una llamada ya aceptada por tu sistema no se vuelve a emitir.

Probar el origen del lado del receptor

Las peticiones de webhook_action llevan la autenticación que tú configuras (auth_mode): es ella la que prueba el origen ante tu sistema. Para el sentido inverso — verificar la firma de lo que betool recibe — consulta Webhook entrante.