Respond to Webhook

In a workflow started by a Webhook Trigger, this node sets the HTTP status and body returned to whoever called the webhook. Without it, a webhook workflow returns a generic 202 Accepted and runs in the background; with it, the caller gets your response synchronously — so you can answer their request with real data.

When to use

• A third-party system (or your own front end) calls your webhook and expects a response — a validation result, a computed value, an acknowledgement payload.
• You're building a small request/response API on top of a workflow.

Configuration

Field	Required	What it does
status	No	The HTTP status code to return (100–599, default 200). Supports {{...}} refs.
body	No	The response body — JSON or plain text. Supports {{...}} refs, so you can return data computed earlier in the workflow.

If body is a JSON string it's returned as JSON (application/json); otherwise it's returned as text.

Example

[Webhook Trigger] → [API Call: look up player] → [Respond to Webhook]
                                                    status: 200
                                                    body: { "risk": "{{gateway_call.data.risk}}" }

The system that POSTed to your webhook receives 200 with that JSON body, instead of a 202.

What it outputs

{ status: 200, body: { … } }

Gotchas

• Webhook workflows only. In a schedule- or event-triggered workflow there's no HTTP caller waiting, so the node has nothing to respond to.
• The workflow runs while the caller waits. The response is synchronous and bounded by a timeout — keep the path to the Respond node fast. Long-running work should stay on the background (no-Respond) path.
• One response wins. If more than one Respond node is on the executed path, the last one to run sets the response.
• Back-compatible. A webhook workflow without a Respond node behaves exactly as before — it returns 202 and runs in the background.