Webhook Response
Return an HTTP response when a selected node completes while the workflow continues.
Use Webhook Response when the caller should receive an acknowledgement before the whole Run completes. The Webhook selects which response node it will use.
Configure the response
The node has fixed inputs:
| Input | Value |
|---|---|
body |
Any JSON value; default is empty text. |
statusCode |
HTTP status number; default is 200. |
headers |
An object of scalar header values; default is an empty object. |
{
"op": "node.add", "as": "response", "type": "webhook-response", "name": "Acknowledge",
"inputs": {
"body": { "kind": "value", "value": "Accepted" },
"statusCode": { "kind": "value", "value": 202 }
}
}
Set the Webhook’s config.options.responseBody to { "kind": "webhook-response", "nodeId": "$response", "timeoutMs": 30000 } in the same batch. Connect an execution path from the Webhook to the response node.
Reply timing
The first successful execution commits an immutable response snapshot. The HTTP caller receives it without waiting for later nodes. Subsequent failures, loop iterations, and retries do not replace that response.


- Input
- POST body: {"message":"Please check my order"}
- Expected result
- HTTP 202 with text "Received: Please check my order" and X-Workflow: ticket-intake.
- Before running
- Publish the Flow on a deployment with an externally reachable Webhook endpoint.
The node has no business outputs and allows downstream execution edges. Multiple response nodes can exist, but each Webhook selects one reachable node. If a successful Run skips its selected response node, HTTP returns an error.
Boundaries
Headers can be fixed entries or a whole-object input source; per-entry dynamic sources are not supported. Deployment header and origin policies still apply. A response from a nested workflow cannot answer an enclosing Run’s HTTP request.
This node has no node retry or error-handling policy. See Webhook for response modes and timeouts.