Triggers
How workflows start — webhook, schedule, and connector-native triggers.
Triggers
A trigger is the first node in a workflow — the event that starts every run. Each workflow has exactly one trigger. Pick the type that matches how the outside world tells you something happened.
Webhook trigger
The Inbound Webhook trigger gives you a unique URL. Whatever sends a request to that URL kicks off the workflow.
When you add the trigger and publish the workflow, Triggo generates a URL of the form:
https://your-workspace.triggo.app/webhooks/<subscription-id>The endpoint accepts POST requests. The full request body is parsed as JSON and exposed to downstream nodes as {{trigger.output.body}}, alongside {{trigger.output.timestamp}} (ISO-8601 timestamp of receipt).
A single curl call is enough to test it end to end. For a fictional new-lead notification:
curl -X POST https://your-workspace.triggo.app/webhooks/<subscription-id> \
-H "Content-Type: application/json" \
-d '{"email":"alice@acme.io","name":"Alice"}'The next node in the workflow can read {{trigger.output.body.email}} and {{trigger.output.body.name}}. No connection or credentials are required — webhooks are connectionless. If you configure a webhook secret on the trigger, Triggo verifies the HMAC signature automatically.
Schedule trigger
The Schedule trigger runs the workflow on a clock. It has two modes:
- Fixed interval — every N seconds. Minimum 60 seconds, maximum 86 400 seconds (24 hours), enforced at activation.
- Cron expression — standard 5-field cron (
minute hour day-of-month month day-of-week). Examples:0 9 * * MON-FRI(weekdays at 9:00),*/5 * * * *(every 5 minutes),0 0 * * *(midnight daily).
Cron schedules accept an IANA timezone string (e.g. Europe/Moscow, UTC); it defaults to UTC. Scheduling is delegated to BullMQ's upsertJobScheduler with pattern + tz, so any expression BullMQ accepts works here.
The trigger output exposes timestamp, scheduleType ("interval" or "cron"), and expression — the literal cron string or "every 300s" for intervals.
Connector-native triggers
Some connectors expose their own event streams — typically via the vendor's webhook system or polling — so you don't need a separate webhook trigger to react to changes inside that service.
- AmoCRM —
lead_added,lead_edited,lead_deleted,lead_restored,lead_status_changed,lead_responsible_changed,contact_added,contact_edited,contact_deleted,contact_restored,contact_responsible_changed,company_added,company_edited,company_deleted,company_restored,company_responsible_changed,task_added,task_edited,task_deleted,task_responsible_changed,unsorted_added,unsorted_edited,unsorted_deleted,note_lead_added,note_contact_added,note_company_added,catalog_element_added,catalog_element_updated,catalog_element_deleted,message_received,talk_added,talk_edited— fires on the matching CRM event. - Bitrix24 —
new_deal,deal_updated,new_contact,new_lead,task_added,task_updated: fires on the matching CRM/task event. - Gmail —
new_email: fires when a new message arrives in the connected mailbox. - Google Sheets —
row_changed: fires when a row in a watched sheet is added or edited. - HubSpot —
new_contact: fires when a new contact is created. - MAX —
new_message,callback_query: fires on incoming MAX messenger messages and inline button callbacks. - Telegram —
new_message,callback_query,chat_join_request,bot_event: fires on incoming Telegram updates for the connected bot.
Connector-native triggers require a connection to the underlying service so Triggo can subscribe on your behalf.
Choosing a trigger
- An external system will ping us when something happens? → webhook.
- Something needs to run on a clock? → schedule.
- A specific service has its own event stream? → connector-native.
When in doubt, start with the webhook trigger — it works with any service that can send an HTTP request — and switch to a connector-native trigger later if the integration offers richer event metadata.