Triggers
Reference for the trigger types that start a workflow, from API calls and webhooks to schedules, inbound email and events in other systems.
A workflow has one trigger, stored in trigger in the workflow definition. It decides what starts a run and what the run receives as input. For the plain-language version, see Choose when a workflow runs.
Trigger types
| Trigger | trigger.type | Run starts when | Run input |
|---|---|---|---|
| API | api | You call POST /workflows/:id/run | The input object you send |
| Webhook | webhook | A connected provider sends an event, or something posts to your custom webhook URL | input.webhookEvent |
| Schedule | schedule | A cron expression or interval comes due | input._schedule |
| Inbound email | email_event | An email reaches the workflow's own address | input.inboundEmail |
| App events | hubspot_event, airwallex_event | A HubSpot or Airwallex event arrives for a connected account | input.webhookEvent |
| Slack | slack_event, slack_slash_command, slack_interactive | A message, command or button click arrives from a connected Slack workspace | input.slackEvent |
In Studio, triggers are blocks in the Triggers group of the block palette: API, Schedule, Inbound Email, Airwallex, and the HubSpot and Slack blocks added in trigger mode. The Webhook trigger has no block; you set it in the definition through the API.
Rules that apply to every trigger
- Only active workflows start. A trigger starts a run only while the workflow's status is
active. Activate a workflow withPOST /workflows/:id/activate, or Deploy in Studio. Events that arrive while a workflow is a draft, paused or archived do not start a run and are not queued for later. - Activation sets the trigger up. A schedule is created, and an inbound email address is provisioned, when the workflow is activated. Archiving removes both.
- One trigger per workflow. To start the same steps from two triggers, build two small workflows that each call a shared one with a Sub-Workflow step.
- Manual runs work for any trigger.
POST /workflows/:id/runand Studio's Run start an active workflow whatever its trigger type. Post a sample payload in the same shape the trigger produces to test it, for example{ "webhookEvent": { "payload": { … } } }for a webhook workflow. - Design for repeats. Providers can send the same event more than once. The webhook and Slack paths start a run for each delivery they accept, so make steps safe to repeat, or check for an existing record first. Inbound email starts at most one run per email.
Reading trigger data in steps
Every trigger writes into input, so steps read it with {{input.<path>}}. The only other trigger value is {{trigger.connectionId}}, the connection that fired the trigger. See Variable references for each trigger's paths.
Errors, retries and timeouts
Configure how a step behaves when it fails, how retries and timeouts work, and the shape of the error responses the Loopfour API returns.
API trigger
Start a workflow run with an API call, pass input in the request body, and read the run that the call creates through the Runs API.
Loopfour