Returning Data to a Synchronous Webhook Caller

Pair a Webhook trigger with a Response node so the HTTP system that calls your workflow gets a value back in the same request, instead of the default acknowledgement.

Overview

By default, a workflow started by a Webhook trigger answers the caller immediately with a 202 acknowledgement that carries an executionId, then runs the rest of the steps asynchronously. That is the right behavior for most integrations: the caller does not have to wait for downstream connectors to finish. But some callers need an actual answer in the same HTTP request, for example a lookup endpoint that should return a computed total, a validation result, or a record that your workflow assembled. The Response node exists for exactly this case: it holds the HTTP connection open and returns the value you choose once the workflow reaches that node.

Think of the Response node as the reply half of a request-response pair. The Webhook trigger receives the inbound request and exposes its parsed body to the rest of the workflow; the Response node sends a chosen value back along that same connection. Only the Webhook trigger supports this pattern in Spojit, because it is the only trigger backed by a live HTTP caller waiting on the other end. When your workflow reaches a Response node, the caller receives whatever you put in its body instead of the standard 202 acknowledgement.

Before You Start

A workflow whose trigger is set to Webhook. See Setting Up a Webhook Trigger for the trigger URL and signing connection.
The caller you control must be able to read the HTTP response body of its POST, not just fire and forget.
An understanding of how upstream step output flows into later nodes. See Working with Variables and Templates.

Steps

The pattern is: receive the request on the Webhook trigger, do whatever work you need in between, then end the relevant path on a Response node that returns the value.

Step 1: Confirm the trigger is a Webhook

Open the workflow in the Workflow Designer, select the trigger node, and confirm Trigger Type is set to Webhook. The trigger parses the inbound JSON body and makes it available to later nodes as {{ input }} (or {{ input.raw }} when the body is not JSON). A Manual, Schedule, Email, or Mailhook trigger has no live HTTP caller waiting, so a Response node has nothing to reply to.

Step 2: Build the work that produces the value

Add the nodes that compute whatever you want to return. For a deterministic lookup, use a Connector node in Direct mode, for example the Shopify connector with get-order mapped from {{ input.orderId }}, or the MongoDB connector with find-documents. To reshape the result into the exact payload the caller expects, add a Transform node so the response is clean and predictable.

Step 3: Add the Response node

Drag a Response node onto the canvas and connect it after the node that produced your value. Open its properties panel and set the body to what you want the caller to receive. You can return a literal value, a single upstream variable such as {{ get_order_result }}, or a templated object that pulls fields from several earlier steps, for example:

{
  "orderId": "{{ input.orderId }}",
  "status": "{{ get_order_result.financial_status }}",
  "total": "{{ get_order_result.total_price }}"
}

Reaching the Response node sends this body back along the open HTTP connection, replacing the default 202 acknowledgement.

Step 4: Handle the branches that should not reply synchronously

If your workflow branches with a Condition node, only the paths that end on a Response node return a value synchronously. Decide deliberately which branch answers the caller. A common shape is a validation branch that returns a rejection payload on the false path and the assembled record on the true path, with a Response node at the end of each. Paths that do not reach a Response node fall back to the standard asynchronous acknowledgement.

Step 5: Test from the calling system

Send a real POST to the webhook URL from the system that will call it, signed with the configured signing connection, and read the HTTP response body. You should get back the payload defined in your Response node rather than the 202 with an executionId. Confirm the run also appears in execution history. See Understanding Execution Logs to inspect what each step produced.

Synchronous Response vs Default Async 202

Choose a synchronous Response when the caller genuinely needs the answer in the same request: a lookup that returns a record, a validation endpoint that returns pass or fail, or a price or availability check. Keep the default async 202 when the caller only needs confirmation that the request was accepted, when the workflow involves long-running connectors, AI steps, or a Human approval pause, or when the work is naturally fire-and-forget such as syncing an order into another system. The async model lets the caller move on immediately while Spojit finishes the rest of the run.

Tips

Keep synchronous workflows short. The caller is holding an open connection until the Response node is reached, so put fast, deterministic Direct-mode steps on the synchronous path and move slow or optional work to a branch that does not reply.
Use a Transform node right before the Response node to lock the response shape, so the caller always receives a stable contract even if an upstream connector changes its raw output.
You can scaffold the request-response pair quickly by asking Miraxa, the intelligent layer across your automation, something like "Add a Response node after my Transform node that returns {{ order_summary }}" while you have the workflow open.
If you also need to notify someone, keep the Response node for the caller and add a separate Send Email or Slack step on a non-replying branch so the email or message does not delay the synchronous answer.

Common Pitfalls

Adding a Response node to a workflow whose trigger is not Webhook. A Manual, Schedule, Email, or Mailhook trigger has no live caller to reply to, so the node has no effect.
Expecting a synchronous reply while a slow path runs. If the path to the Response node passes through a long connector call, an AI step, or a Human approval pause, the caller waits the whole time. Move that work off the synchronous path or accept the default 202.
Leaving a branch with no Response node when the caller expects one on every path. A Condition branch that never reaches a Response node returns the default acknowledgement instead, which can look like a missing answer to the caller. Place a Response node at the end of each path that must reply.
Returning raw connector output directly. Connector responses can be large and can change shape. Pass them through a Transform node first so the caller gets only the fields it needs.