Do I have to send a response back to the caller?

Only if the calling system expects one. Some webhook providers require a response to confirm delivery; others do not. If a response is required, add a Respond to Webhook node. If not, the node is optional — though it is good practice to include it for observability.

Can I reuse the same webhook URL for multiple automations?

No. Each automation gets its own unique URL. If multiple automations need to react to the same event, either fan out from a single receiving automation or register the webhook URL with the external system separately for each.

What happens if my automation takes a long time to respond?

Most webhook providers have a timeout of 5–30 seconds. If the automation does not reply within that window, the provider may mark the delivery as failed and retry. Consider placing the Respond to Webhook node early in the flow to acknowledge receipt quickly, then continue longer processing in subsequent steps.

The Webhook Trigger gives an automation a unique HTTP endpoint. When an external system calls that URL, the automation starts immediately — with the request body, headers, and query parameters all available to downstream steps. Use it to react to events pushed from outside: form submissions, payment notifications, messages from other platforms — without polling for changes.

Overview

The Webhook Trigger turns an automation into an HTTP listener. You configure the expected data shape once; the platform validates every incoming request against it and passes the parsed payload into the automation's data context. The calling system drives timing — your automation reacts the moment the request arrives.

Webhook Trigger node configuration

The Webhook URL

Each automation with a Webhook Trigger receives a unique URL generated by the platform. Share that URL with the external system that will call it. Any HTTP request to the URL starts a new automation run, and the URL stays stable across automation edits.

The request body, headers, and query parameters of each incoming request are all captured and made available as named data fields within the automation, so downstream steps can reference them directly.

Request Data

The Webhook Trigger surfaces three data sources from each incoming request:

Request body — the payload sent by the caller, typically JSON. You define the expected shape in the trigger configuration; the platform validates incoming bodies against that schema.
Headers — HTTP headers sent with the request, available for reading authentication tokens, content-type hints, or caller-specific metadata.
Query parameters — key-value pairs appended to the URL (for example, ?source=crm&event=lead), useful when callers encode lightweight context in the URL rather than the body.

Defining the data shape up front lets downstream steps map fields without guesswork, and lets the platform reject malformed payloads before they reach your logic.

Responding to the Caller

A webhook automation does not send a response automatically. To reply, add a Respond to Webhook node at the point where you want to answer the caller. You set the HTTP status code and the response body in that node — use it to acknowledge receipt, return a result, or send an error.

Many webhook providers require a timely response to confirm delivery. If your automation does not reply within the provider's timeout window, the provider may mark the delivery as failed and retry. Place a Respond to Webhook node on every execution path so the caller always receives an answer, even when an error occurs.

Cover every branch: If your automation splits on a Condition node or similar, add a Respond to Webhook node on each branch. A branch that exits without responding leaves the caller waiting until it times out.

Data Shape Validation

The trigger validates incoming requests against the schema you define. A request that does not match the expected shape is rejected before the automation run begins. This protects downstream steps from unexpected or missing fields and gives the caller a clear, immediate error signal when their payload is malformed.

Security Considerations

The webhook URL is publicly accessible — it is designed to be called by external systems outside of UnifyApps. Anyone with the URL can send a request to it and invoke the automation. Two built-in measures help you control what gets through:

Data shape validation — incoming requests are validated against the data shape you defined, so malformed payloads are caught up front and rejected before the automation run begins.
Authentication via headers — headers are available for reading authentication tokens. Callers can include auth tokens in request headers, and downstream steps in your automation can verify those tokens before proceeding with any logic.

Treat the webhook URL like a secret. Share it only with the systems that need to call it, and use header-based authentication to verify that incoming requests come from trusted sources.

Notes

Keep the following in mind when configuring a Webhook Trigger.

The webhook URL is unique per automation. Do not share one URL across multiple automations — each should have its own endpoint.
Define the expected data shape in the trigger configuration so downstream steps can reference body fields by name and the platform can validate incoming requests.
Add a Respond to Webhook node on every execution path. A path that exits without a Respond node leaves the caller waiting indefinitely.
All three data sources — body, headers, and query parameters — are available in the automation's data context. Use headers for auth tokens and query parameters for lightweight caller context.
Malformed payloads — those that fail schema validation — are rejected before the automation run starts, so your logic only processes clean data.

If the external system requires a specific response format or status code to confirm delivery, configure the Respond to Webhook node to match those expectations exactly before deploying.