Webhook Response
Answers the HTTP request that started the run with a status code, headers, and a body the flow builds. Reach for it when the system calling a Webhook trigger needs a result back—a lookup that returns a record, a form that shows a confirmation, or a validation endpoint that answers 400 with a reason.
The step answers only a request whose Webhook trigger has Respond set to From a Webhook Response Step, which holds the request open until a Webhook Response step answers it. See Answering the sender.
Fields
| Field | Description |
|---|---|
| Status Code | The HTTP status sent back, 200 by default. Use a 2xx code for success, or a 4xx or 5xx code to report a problem. Accepts a variable, so an earlier step can choose it. Redirects (3xx) are not supported. |
| Headers | Headers sent with the response, as name and value pairs. Values accept variables. The cookie headers (Set-Cookie, Set-Cookie2), the redirecting ones (Location, Refresh), Content-Length, Content-Security-Policy, X-Content-Type-Options, and the connection headers such as Transfer-Encoding cannot be set. |
| Body | The body: a value picked from an earlier step, or text you type. An object, list, number, or true/false is sent as JSON with Content-Type: application/json; text is sent as written, as text/plain unless Headers sets a Content-Type. To send a body that mixes text and values, such as an HTML page, build it with an input mapping (a String Template, for example) and pick that. Leave it empty to send no body. At most 1 MB. |
What later steps see
| Field | Description |
|---|---|
answered | Whether this response is the one the request got. false when the request had already been answered, or when the run was not started by a Webhook trigger waiting for this step. |
status | The status code this step built. |
headers | The headers this step built, Content-Type included. |
body | The body this step built, as text, or nothing when it had none. |
Behaviour
Answering is a step like any other, not the end of the run: the steps after it run on once the sender has its answer.
A request gets one answer. The first Webhook Response step to run answers it, on whichever server the step runs, and a later one—on a parallel branch, or after the request timed out—logs which answer went out and completes with answered set to false. Neither case fails the run. Put a Webhook Response step on each branch that should answer, and let the branches decide which one runs.
A step in a run that nothing waits on—started by a trigger that answers its requests on receipt, or by something other than a webhook—logs that there was nothing to answer. A run started by Fire Test or a replay has no sender waiting, so its response is recorded on the delivery, where the Deliveries screen shows it.
Every response carries X-Content-Type-Options: nosniff and Content-Security-Policy: sandbox. The webhook URL is on the CMS's own host, so a browser shows an HTML body in a sandbox that runs no script.
A dry run answers the request too. Answering the sender changes nothing in another system, and calling a draft's webhook URL is how to test the response.