Where the inbound webhook channel receives external events to process, the webhook_action node does the reverse: it emits an HTTP request to your systems from any point in a pipeline — the equivalent of Make's "HTTP" or Zapier's "Webhooks" modules.
Why
You probably already have:
- An alerting system (PagerDuty, Opsgenie, Slack).
- An ITSM tool (Jira, ServiceNow) to manage tickets.
- A custom dashboard that aggregates your operational status.
Rather than asking these systems to poll betool, have your pipelines notify them: place a webhook_action node at the point in the graph where the event occurs (a qualified email, a filter passed, a scheduled report…). Combined with the Schedule channel, it is also the basis for recurring pushes to your systems.
Node configuration
| Field | Role |
|---|---|
url | Target URL (templatable) |
method | GET / POST (default) / PUT / PATCH / DELETE |
headers / query | Dictionaries of {name: template} |
body_mode | none / json (default) / form / raw / mapper / multipart |
body_template | Body template (json / form / raw modes) |
mapping_spec | Body built through the payload mapper (recommended) — nesting, arrays, transformations |
auth_mode | none (default) / bearer / basic / api_key_header / oauth2 (client credentials) |
auth_config | Auth mode parameters: {token}, {user, password}, {header, value} or {credential_id} |
timeout_ms | Default 30,000 ms |
retry_count | Number of retries (default 0, maximum 10), exponential backoff |
accepted_statuses | HTTP codes considered a success (default: 200, 201, 202, 204) |
output_key | Flow key where the response is written (default webhook.response) |
Templating
URL, headers, query and body interpolate flow keys using the {path} syntax:
{
"event": "order_qualified",
"order_id": "{webhook.payload.order_id}",
"verdict": "{exchange.result}"
}
Authentication
- Credentials for the
bearer/basic/api_key_headermodes (the token, the password, the header value) are stored in the node configuration, but never come back out in plain text: the editor, the admin API, the MCP tools and proposals only show a "secret saved" marker. In the editor, the field shows "•••••• saved — type to replace": leave it empty to keep the secret, type a value to replace it, or click Remove to clear it. The identifier (user) and the header name (header) remain readable. - Copy-pasting or duplicating a node does not copy its secrets: enter them again on the copy.
- In
oauth2mode (client credentials), the node only carries a credential reference; the secret lives in the organisation's OAuth storage, is never returned on read, and the token is obtained (then refreshed) at execution time. The same credential serves several nodes, and rotating the secret requires no pipeline to be edited.
Sending files (multipart)
The multipart mode (RFC 7578) sends text fields and attachments in the same request — for partners that only accept multipart/form-data. Files are referenced by their object-store key and re-read at send time (20 files and 25 MB at most); a key outside your organisation's scope is refused, and a send whose attachment is missing is aborted rather than emitted incomplete.
Retries & errors
- A status outside
accepted_statuses, a timeout or a network error triggers a retry with exponential backoff (0.5 s, 1 s, 2 s, 4 s…), up toretry_countretries. - The response (
status,headers,body) is written underoutput_key, with anerrorkey once retries are exhausted: downstream nodes can read the result and trigger a fallback path on failure. The result is visible in the history. - No double send: if the execution is replayed (resumption after a redeployment, queue retry), a call already accepted by your system is not re-emitted.
Proving the origin on your receiver
Requests from webhook_action carry the authentication you configure (auth_mode): that is what proves the origin to your system. For the reverse direction — verifying the signature of what betool receives — see Inbound webhook.