Blocks
Respond to webhook
The respond-to-webhook step: send a custom HTTP response back to the caller mid-run — status, headers, and a body shaped from the payload.
Send a custom HTTP response back to whoever called your webhook — status, headers, and a body you shape — while the workflow keeps running downstream.
Only meaningful when the webhook trigger's response mode is respond step: in the other modes the trigger already answered (202 immediately) and this step's output is ignored.
Config
Status, headers, and the body expression.
- Status — 100–599, default 200.
- Headers — a map literal
(
%{"content-type" => "application/json"}) or an expression returning one. - Body — an expression over
payload(not{{ }}templating):payloadalone echoes the upstream output;%{status: "ok", id: payload["id"]}shapes a custom JSON response.
Patterns
- Synchronous API — webhook → process → respond with the result: your workflow is the endpoint.
- Fast ack, custom shape — respond early with
%{received: true}, keep the heavy work running after.
Gotchas
- The caller waits until this step runs — keep the path from trigger to respond short, and put slow work after the response.
- Headers and body are expressions —
{{ payload.x }}mustache syntax won't work here (this is the one Act step where that's true).