Loopfour
Triggers

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

Triggertrigger.typeRun starts whenRun input
APIapiYou call POST /workflows/:id/runThe input object you send
WebhookwebhookA connected provider sends an event, or something posts to your custom webhook URLinput.webhookEvent
SchedulescheduleA cron expression or interval comes dueinput._schedule
Inbound emailemail_eventAn email reaches the workflow's own addressinput.inboundEmail
App eventshubspot_event, airwallex_eventA HubSpot or Airwallex event arrives for a connected accountinput.webhookEvent
Slackslack_event, slack_slash_command, slack_interactiveA message, command or button click arrives from a connected Slack workspaceinput.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 with POST /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/run and 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.

On this page