Configuring the Webhook Trigger's Synchronous Response

Overview

Webhook triggers include a Synchronous result mapper that determines what your workflow sends back to the caller once execution completes successfully. Previously, this mapper could only shape the response body — the caller always received a 200 status code, regardless of what the mapper returned.

In this article, we'll be covering how the synchronous result mapper can now return a custom HTTP status code and body, including how to answer with a 202 for requests still being processed, or a 4xx for requests your workflow logic rejects.

Understanding how the synchronous result mapper works

The synchronous result mapper runs after a webhook-triggered workflow execution completes with a "Success" status. It receives the workflow's final state and determines the response sent back to the caller.

The mapper can return:

• A plain value — the caller receives a 200 status code with that value as the response body (unchanged behavior)
• { statusCode, body } — the caller receives the specified status code, with body as the response body

A custom status code only applies to a workflow execution that completes with a "Success" status. A failed execution or a timeout still returns their existing fixed status codes — 500 for a failure, 408 for a timeout — regardless of what the synchronous result mapper would have returned.

Configuring a custom status code and body

You configure the synchronous result mapper the same way you configure a skip execution mapper — from the webhook trigger node.

1. Open your workflow in the builder
2. Click on your webhook trigger node
3. Locate the Synchronous result mapper field
4. Click to open the code editor
5. Return { statusCode: <code>, body: <value> } instead of a plain value

The body field is optional. If you omit it, the caller receives the status code with no response body.

Answering asynchronously with a 202

A common pattern is to acknowledge a request immediately with a 202 while the real work continues in the background:

1. Validate the incoming request in the webhook workflow
2. Add a Start Workflow node to launch the workflow that does the actual provisioning or processing work, with Fire and forget enabled
3. In the synchronous result mapper, return { statusCode: 202 }

Because Fire and forget doesn't wait for the child workflow to complete, the webhook workflow reaches its End node quickly — response time depends on the parent workflow's own node count, not on how long the child workflow takes to finish.

Understanding limitations

• Custom response headers aren't supported.
• Responses are always sent as JSON. XML and plain-text output aren't supported, even for triggers that accept XML input.
• If a workflow has both a workflow-level output mapper and a synchronous result mapper configured, the output mapper takes precedence — the synchronous result mapper's status code is ignored.

The synchronous result mapper follows the same { statusCode, body } return shape as the skip execution mapper. See Skip Execution Mapper for how that mapper controls the response when an execution is skipped before it starts, and Understanding Workflow Trigger Types for an overview of webhook triggers.