Triggers and webhooks
Triggers let an event in one of your tools — a Slack message, a GitHub pull request, a Notion page update — start a workflow execution in Studio. You register a webhook for a provider, paste its URL into the provider's settings, then attach one or more triggers to it. Each trigger says which events it reacts to and what to run.
The platform handles signature verification, deduplication, delivery retries, and per-event status tracking, so you only pick a webhook, an optional filter, and what to run.
How triggers work
| Term | Definition |
|---|---|
| Webhook | A registered endpoint for one provider, with its signing secret. Its URL has the form https://webhooks.mistral.ai/providers/{provider}/sources/{webhook_id}. |
| Trigger | A rule attached to a webhook: an optional filter plus one action to run when an event matches. |
| Provider | The upstream tool sending events: Slack, GitHub, Notion, Linear, Lucca, or Ashby. |
| Event type | A provider-specific string derived from each delivery, for example push for GitHub or app_mentioned for Slack. Filters usually match on it. |
| Filter | A JMESPath expression evaluated against the event's JSON body. No filter means every event matches. |
| Owner type | workspace (visible to the whole workspace) or user (visible to its creator only). A trigger must have the same owner type as its webhook. |
A triggered workflow runs as the user who created the trigger. Triggers can't start on-behalf-of workflows.
Each delivery is tracked as a trigger event with a status — submitted, triggered, or failed — so you can see which events reached their target.
To start a workflow from a webhook, see Triggers and webhooks for workflows.