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

The respond-to-webhook step in the Inspector 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): payload alone 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).