Choose Webhook as the trigger. The designer shows two addresses straight away:

  • Production URL — the one to give the other system. It starts the workflow once it is published and switched on. Keep it secret — anyone who has it can start the workflow.
  • Test URL — for while you build. Press Listen for a test event, send anything to it within two minutes, and a test run of your draft starts with what was sent. It takes one call per Listen, and answers 404 when nobody is listening.

What the call brings

The address takes GET or POST. The method, headers, query and body are available to the steps as {{ trigger.method }}, {{ trigger.headers }}, {{ trigger.query }} and {{ trigger.body }}. Cookies and credentials in headers are left out.

What the caller gets back

Respond, in the Webhook's settings, decides when the caller hears back:

  • Immediately with 200 — received, and the run has started. The caller does not wait.
  • When the workflow finishes — the caller waits and gets what the last step gave, as JSON; 500 if the workflow failed.
  • Using a Respond to Webhook step — add that step where the answer is ready and set its status, headers and body. The caller waits until it runs; the steps after it carry on with the same data, so put anything slow after it. If the run ends without reaching it, the caller gets 500.

A caller waits 30 seconds at most. After that it gets 202 with the run's id, and the run carries on. The Test URL answers the same way, so you see what the caller will get.

An answer leaves from our address, so a Respond to Webhook step cannot redirect (3xx), set cookies, or change the headers that keep the address safe.

Whatever the setting:

  • 404 — no such address, or the workflow is switched off or unpublished.
  • 413 — the call brought more than 256 KB.
  • 429 — more than 120 calls a minute to this address.