Webhook trigger

The Webhook trigger starts a dataflow whenever an HTTP request is received on a unique webhook URL. Each webhook trigger generates its own unique URL, for example https://{yourUrl}/datahub/hooks/e03a0e70-cc77-44e4-9295-7323daeeb73f. As soon as a request is received on this URL, the dataflow is triggered immediately: there are no scheduling or timing options involved.

Setting it up

The recommended workflow is:

1. Add the Webhook trigger to the dataflow and save the dataflow.
2. Copy the generated webhook URL.
3. Configure the external application to send a request to this URL.
4. Send a test request from the external application.
5. Return to the dataflow and open the webhook trigger configuration.

In the Response body tab, the most recent received request is shown: the configuration dialog automatically displays the received data.

In the Preview tab, the visualization depends on the selected output type:

• JSON → Table: the incoming JSON is transformed into a table structure, and you can select which columns should be exposed to the dataflow.
• JSON: the request body is shown as formatted JSON.
• Raw: the exact HTTP request and response information is shown, for example an HTTP status code like 204.

When JSON → Table is selected and columns are chosen, you can switch to the Columns tab to adjust the value types if needed.

Behavior

• The trigger is activated every time a webhook request is received.
• The webhook responds with HTTP 200 immediately after receiving the request.
• The response is sent before the dataflow has finished executing: the dataflow itself may continue running for several seconds after the response is returned.

Security considerations

The webhook does not require any form of authentication or authorization. Because of this:

• Treat the webhook URL as a secret.
• Do not expose the URL publicly unless strictly necessary.
• Rotate the webhook by recreating the trigger if the URL is compromised.

When to use it

Use the Webhook trigger when a dataflow needs to be started by an external system or event.

Typical use cases include:

• Receiving events from external applications
• Triggering a dataflow when an order is created in an ERP system
• Event-driven integrations where polling or scheduling is not desired

Tips

• Always send a test request after creating the trigger to inspect the incoming data structure.
• Prefer JSON → Table when the payload needs to be processed further in the dataflow.
• Use Raw output only for debugging or advanced inspection of the HTTP request.