Workflow triggers
A workflow-trigger webhook starts a workflow when a verified event arrives, passing the request payload as the run's input. Use it to turn an external event into automated work — triage an incoming issue, kick off a deploy pipeline, fan out a notification.
If instead the event should just be seen by the team, use a channel post.
Authentication
Workflow triggers verify a real provider's event signature, so they expose the full set of signing schemes. Pick the one that matches whoever sends the events:
For the provider schemes (Stripe, GitHub, Svix) you don't compute the signature yourself — configure the provider's webhook with the endpoint URL and its signing secret, and the provider signs each request. Only requests that verify against the endpoint's secret start a run. See verifier schemes for the header each scheme expects.
Input
The raw request body is passed to the workflow as its input, so the workflow's first node receives exactly what the sender posted. Parse and branch on it inside the workflow.
Response
Workflow triggers choose what the sender receives back:
- On received (202 immediately) — acknowledge as soon as the event is verified and the run starts. Default, and right for fire-and-forget senders.
- Last node output — respond with the last node's output once the run finishes.
- Custom response node — respond with the output of a designated response node.
A response timeout bounds how long the sender waits for the synchronous
(last_node / response_node) modes before the request returns. Keep it within
the sender's own timeout.
Identity
A workflow trigger runs the workflow as its owner. To route events to a different owner or workflow, create a new endpoint — the binding is fixed once the endpoint exists.