Вызов ваших внешних систем из pipeline — узел webhook_action, шаблоны, аутентификация, повторные попытки.

Исходящие webhook

Если канал входящего webhook принимает внешние события для обработки, то узел webhook_action делает обратное: он отправляет HTTP-запрос в ваши системы из любой точки pipeline — аналог модулей «HTTP» в Make или «Webhooks» в Zapier.

Зачем

У вас, вероятно, уже есть:

Система оповещений (PagerDuty, Opsgenie, Slack).
ITSM-инструмент (Jira, ServiceNow) для управления тикетами.
Кастомный дашборд, агрегирующий ваше операционное состояние.

Вместо того чтобы заставлять эти системы опрашивать betool, пусть их уведомляют ваши pipelines: разместите узел webhook_action в той точке графа, где происходит событие (квалифицированное письмо, пройденный фильтр, запланированный отчёт…). В сочетании с каналом Планирование это также основа регулярной отправки данных в ваши системы.

Конфигурация узла

Поле	Назначение
`url`	Целевой URL (поддерживает шаблоны)
`method`	`GET` / `POST` (по умолчанию) / `PUT` / `PATCH` / `DELETE`
`headers` / `query`	Словари `{имя: шаблон}`
`body_mode`	`none` / `json` (по умолчанию) / `form` / `raw` / `mapper` / `multipart`
`body_template`	Шаблон тела (режимы `json` / `form` / `raw`)
`mapping_spec`	Построение тела через payload mapper (рекомендуется) — вложенность, массивы, преобразования
`auth_mode`	`none` (по умолчанию) / `bearer` / `basic` / `api_key_header` / `oauth2` (client credentials)
`auth_config`	Параметры режима аутентификации: `{token}`, `{user, password}`, `{header, value}` или `{credential_id}`
`timeout_ms`	По умолчанию 30 000 мс
`retry_count`	Число повторных попыток (по умолчанию 0, максимум 10), экспоненциальная задержка
`accepted_statuses`	HTTP-коды, считающиеся успешными (по умолчанию: 200, 201, 202, 204)
`output_key`	Ключ потока, в который записывается ответ (по умолчанию `webhook.response`)

Шаблоны

URL, заголовки, query и тело подставляют ключи потока с помощью синтаксиса {путь}:

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

Аутентификация

Учётные данные режимов bearer / basic / api_key_header хранятся в конфигурации узла: они остаются видимыми для участников, которые могут открыть этот pipeline.
В режиме oauth2 (client credentials) узел содержит только ссылку на учётные данные; секрет хранится в OAuth-хранилище организации, никогда не возвращается при чтении, а токен получается (и затем обновляется) во время выполнения. Именно этот режим следует предпочитать для чувствительного секрета.

Отправка файлов (multipart)

Режим multipart (RFC 7578) отправляет текстовые поля и вложения в одном запросе — для партнёров, принимающих только multipart/form-data. Файлы указываются по их ключу в object store и перечитываются в момент отправки (максимум 20 файлов и 25 МБ); ключ вне периметра вашей организации отклоняется, а отправка, в которой отсутствует вложение, прерывается, а не выполняется в усечённом виде.

Повторные попытки и ошибки

Статус вне accepted_statuses, тайм-аут или сетевая ошибка запускает повторную попытку с экспоненциальной задержкой (0,5 с, 1 с, 2 с, 4 с…), до retry_count повторных попыток.
Ответ (status, headers, body) записывается под output_key, с ключом error после исчерпания попыток: нижестоящие узлы могут прочитать результат и запустить резервную обработку в случае сбоя. Результат виден в истории.
Без двойной отправки: если выполнение воспроизводится (возобновление после повторного развёртывания, повтор из очереди), вызов, уже принятый вашей системой, не отправляется повторно.

Подтверждение источника на стороне получателя

Запросы webhook_action несут аутентификацию, которую настраиваете вы (auth_mode): именно она подтверждает источник для вашей системы. Для обратного направления — проверки подписи того, что betool получает, — см. Входящий webhook.