Webhook Triggers
Webhook Triggers
Two webhook-based trigger types for receiving external HTTP requests into a workflow — Catch Hook for asynchronous fire-and-forget ingestion, and Sync Hook for synchronous request-response flows.
Overview
Both trigger types are available as events under the Webhook app in the workflow builder. Each generates a unique, persistent URL upon activation.
Comparison at a glance
| Aspect | Catch Hook | Sync Hook |
| Execution model | Asynchronous | Synchronous |
| HTTP response to caller | Immediate 200 OK / 202 Accepted | Held open until Response Node is reached |
| Caller receives workflow output | No | Yes — via Response Node |
| Response Node required | No | Yes |
| Best for | High-volume event ingestion, third-party webhooks | API-style flows where the caller expects a structured response |
Catch Hook
Catch Hook is an asynchronous webhook trigger. It accepts an incoming HTTP request, immediately acknowledges it, and processes the workflow in the background.
- Immediate acknowledgment — as soon as the platform receives a valid request, it returns
200 OKor202 Acceptedto the caller - Decoupled processing — workflow execution is queued and runs in the background; the external sender receives no data generated during execution
- Scalable — the connection is closed immediately, allowing high-volume event ingestion without exhausting connection pools or causing timeouts in the source system
| Method | Data source |
GET | Data parsed from query parameters |
POST | Data parsed from request body (JSON, XML, or Form-data) |
PUT / PATCH | Data parsed from request body — used for update-heavy integration logic |
DELETE | Used to trigger cleanup or removal workflows based on an identifier |
All incoming headers, query parameters, and body content are parsed and made available as variables within the workflow context.
Sync Hook
Sync Hook transforms a workflow into a synchronous API endpoint. Unlike Catch Hook, it keeps the HTTP connection open until the Response Node is reached, at which point it returns the processed data to the requester. A Response Node is required in the workflow for Sync Hook to function correctly.
Execution flow
| Step | Component | Description |
| 1 | Client Request | External system hits the Sync Hook URL. Connection is held open. |
| 2 | Processing | The workflow executes sequential or parallel logic nodes. |
| 3 | Response Node | The workflow reaches the Response Node branch. |
| 4 | Data Selection | The Response Node pulls data from the configured allowed nodes only. |
| 5 | HTTP Response | The engine sends the data back to the client and closes the connection. |
| Method | Use case |
GET | Simple data retrieval or trigger signals via query parameters |
POST | Sending JSON payloads or form data (most common) |
PUT / PATCH | Update-heavy integration logic |
DELETE | Workflows managing resource removal |
All incoming headers, query parameters, and body content are parsed and made available as variables within the workflow context.
Response Node
The Response Node is the return point of a Sync Hook workflow. It closes the open HTTP connection by sending the final payload back to the client that triggered the Sync Hook. It has no output schema and is always rendered as a separate branch on the workflow canvas, visually isolated from the main execution flow.
- Synchronous output — closes the loop by sending the final payload back to the HTTP client that triggered the Sync Hook
- Branch isolation — rendered and executed as a separate branch; the normal execution flow continues independently without interruption
- Terminal branch — no nodes can be added below a Response Node within the response branch
When a parent node has a Response Node as one of its children, the execution engine runs two separate loops:
Executes all standard child nodes following the normal execution path and data flow.
Executes the Response Node branch independently, dispatching the response without interfering with normal node execution.
When to Use
- Receiving webhooks from third-party systems (GitHub, Stripe, etc.)
- The caller does not need to wait for or receive a workflow response
- Processing high volumes of incoming events without blocking the sender
- Decoupled, fire-and-forget event ingestion
- The caller expects a structured response from the workflow
- Building an API-style endpoint backed by workflow logic (e.g., user lookup, data enrichment)
- The response must be based on data processed within the workflow
- Latency is acceptable and connection hold time is not a concern
Configuration Example
Examples
Workflow Diagrams
External system is released immediately. Workflow runs independently in the background — caller never sees node outputs.
External system waits until the Response Node is reached. Only the configured Allowed Nodes output is returned.
Things to Know
| Scenario | Behavior |
| Request arrives without Content-Type header | Accepted and processed using a default parsing strategy — not rejected |
| Node added below a Response Node | Rejected by the node connection validator — the response branch is terminal |
| Response Node inserted mid-workflow | Graph is automatically restructured into a fork; downstream normal nodes are not relinked to the Response Node |
| Sync Hook without a Response Node | The HTTP connection will never be closed — a Response Node is required for Sync Hook to function correctly |
| Response Node execution alongside normal nodes | Dual loop execution — Response Node loop runs independently of the normal node loop; neither blocks the other |
Frequently Asked Questions
Catch Hook vs Sync Hook
What is the fundamental difference between Catch Hook and Sync Hook?+
Catch Hook is asynchronous — it acknowledges the request immediately and processes the workflow in the background. The caller receives no output from the workflow.
Sync Hook is synchronous — it holds the HTTP connection open, runs the workflow, and returns the Response Node's output to the caller before closing the connection.
Do both hooks require a Content-Type header?+
No. Both Catch Hook and Sync Hook accept incoming requests without a Content-Type header. When the header is absent, a default parsing strategy is applied automatically.
Can I switch between Catch Hook and Sync Hook without deactivating the workflow?+
Yes. Switching between Catch Hook and Sync Hook is supported in Active mode. The trigger configuration updates in real time and ongoing execution is not disrupted.
Response Node
Why is the Response Node rendered as a separate branch and not inline?+
The Response Node has no output schema. If placed inline, it would visually imply that subsequent nodes depend on its output, which is misleading. Rendering it as a separate branch makes it clear that it is a terminal exit point and that the main execution flow continues independently on a different branch.
Can I add nodes after a Response Node?+
No. The response branch is terminal. The node connection validator rejects any attempt to connect a child node below a Response Node. Normal workflow execution continues on a separate branch unaffected by the Response Node.
What does the Allowed Nodes field in the Response Node control?+
Allowed Nodes controls which upstream nodes' output is included in the HTTP response sent back to the caller. Configuring this prevents internal processing data from being leaked — only the output of the nodes you explicitly allow is returned.
Does the Response Node block the normal execution branch from running?+
No. The execution engine runs two separate loops when a parent node has a Response Node as a child. The Response Node loop and the normal node loop execute independently — neither blocks or alters the data passed to the other.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article