Using Response Nodes

Return data from your workflow to the caller using response nodes.

Overview

A Response node defines the HTTP reply that a workflow sends back to a synchronous caller. It is paired with a Webhook trigger configured to wait for completion, and it controls the status code, headers, and body that the caller receives.

Without a Response node, a webhook trigger acknowledges the request with a default 200 and runs the rest of the workflow in the background. Add a Response node when the caller needs an actual result (a confirmation ID, a structured payload, or a redirect) before it can proceed.

Before You Start

• The workflow must start with a Webhook trigger.
• The trigger must be set to wait for the workflow to complete before responding.

Configuration

1. Add a Response node at the point in the workflow where you want to reply.
2. Set Status code. Default is 200. Use 4xx or 5xx to signal errors to the caller.
3. Optionally add Response headers (for example Content-Type, Location, custom tracing headers).
4. Define the Response body using template expressions to reference earlier step output.

Configuration Reference

• Status code - any valid HTTP status. Defaults to 200.
• Headers - key/value pairs, both sides accept template expressions.
• Body - free-form, usually JSON built from prior step output using {{ step.field }} syntax.

Usage Examples

• Order confirmation - a webhook receives an order, a Connector node creates it in the fulfillment system, and a Response node returns { "status": "processed", "orderId": "{{ step1.order_id }}" }.
• Validation gate - a Condition node detects bad input, and a Response node returns status 400 with a descriptive error body before the workflow ends.

Tips

• Place a Response node on each branch of a Condition node when different cases need different status codes or payloads.
• Keep response bodies small. If the caller only needs an ID, return only that field rather than the full upstream step output.
• For long-running work, respond quickly with an acknowledgement and let the rest of the workflow continue asynchronously after the Response node.

Common Pitfalls

• Response nodes are terminal. Anything wired after one does not execute on that path.
• If the webhook trigger is not set to wait for completion, the Response node is ignored and the caller gets the default acknowledgement.
• Forgetting Content-Type: application/json on JSON bodies can cause some clients to mishandle the reply.

Related Articles

• Setting Up a Webhook Trigger
• Setting Up a Webhook Connection
• Using Condition Nodes
• Working with Variables and Templates
• Understanding Retry and Error Handling

Learn More

• Response node documentation