Workflow Triggers

Triggers determine when and how your workflows execute. Every workflow must have exactly one trigger node as its first node. The trigger produces the initial data that flows downstream through the rest of the workflow.

Strongly AI provides 16 trigger types covering a wide range of execution patterns, from HTTP-based triggers to time-based schedules, file system monitoring, and event-driven architectures. This page covers the most common ones; the full list is in the builder's Triggers category and the Workflows Overview.

---

Webhook

Trigger a workflow over HTTP. Calls are authorized with a Strongly REST API key, or -- for external services like GitHub, Stripe, and Slack -- an HMAC signature using a shared secret. Unauthenticated calls are never accepted.

Use Cases

• GitHub push/pull request event processing
• Stripe payment and subscription notifications
• Slack message and interaction handling
• Custom webhook integrations from any service

Authorization

Method	How it works
REST API key	X-API-Key header with the workflows:execute scope, like every REST endpoint; the run is the deployer's, as every run of a deployed workflow is
External HMAC signature	Provider-specific signature using the configured secret; runs as the workflow owner

Configuration

Setting	Description	Required
Webhook Provider	Signature verification scheme: GitHub, Stripe, Slack, or Generic HMAC (default: Generic)	Yes
Webhook Secret (HMAC)	Shared secret for external HMAC signature verification. Needed only when external signed services call the webhook; leave empty for an API-key-only webhook. Stored encrypted	No
Previous Secret (rotation)	Set during secret rotation: the old secret is also accepted so in-flight callers are not broken. Remove once all callers use the new secret	No
Allowed Events	Filter specific event types per provider (empty allows all)	No
IP Whitelist	Restrict access to specific IP addresses or CIDR ranges	No
Max Body Size (bytes)	Maximum request body size (default: 1MB, max: 10MB)	No
HTTP Method	POST, PUT, GET, or DELETE (default: POST; webhooks carry a JSON body that is HMAC-signed, so POST is the secure default)	Yes
Require Timestamp	Require a timestamp on requests for replay protection (default: false)	No
Max Timestamp Age (seconds)	Maximum accepted timestamp age (default: 300)	No
Rate Limit (per minute)	Maximum requests per minute (default: 10)	No
Rate Limit (per hour)	Maximum requests per hour (default: 100)	No

Provider-Specific Signature Verification

Each provider uses its own signature header:

Provider	Signature Header
GitHub	X-Hub-Signature-256
Stripe	Stripe-Signature (with timestamp)
Slack	X-Slack-Signature
Generic	X-Webhook-Signature

Security Features

The webhook trigger includes the following security measures:

• Authorized calls only, never unauthenticated
• HMAC verification with timing-safe comparison and secret rotation support
• Optional replay protection via timestamp validation
• Per-webhook rate limiting (configurable)
• Request size limits and optional IP whitelisting with CIDR support
• Generic error messages to prevent detail leakage; secrets are never logged

Outputs

Field	Type	Description
provider	string	Webhook provider (generic, github, stripe, slack)
event_type	string or null	The provider's event (for example, push); null for generic
headers	object	Request headers
body	object	The request body (JSON). A call with flat inputs (REST API, agent tool) has them here. A body over 10KB is also stored in full, at request_s3_url
parsed_data	object	Provider-specific fields parsed from the body
method	string	HTTP method
clientIP	string	Caller's IP address
signatureVerified	boolean	Whether an HMAC signature was verified

Execution metadata also records success, trigger_type, provider, event_type, signatureVerified, and body_size.

Webhook URL Pattern

/api/v1/webhooks/{workflowId}

Signature Verification

The HMAC secret is only needed when external signed services (GitHub, Stripe, Slack, or generic HMAC callers) will call this webhook. When you use it, choose a strong random value; it is stored encrypted.

---

Schedule

Trigger workflows on a time-based schedule. Scheduled workflows are deployed as scheduled jobs.

Use Cases

• Daily report generation
• Periodic data synchronization
• Scheduled cleanup and maintenance tasks
• Batch processing jobs on recurring intervals

Schedule Types

1. Run at intervals

Choose an interval that divides the hour or day evenly: every 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 or 30 minutes, or every 1, 2, 3, 4, 6, 8 or 12 hours. For once a day use Run daily; for any other cadence, a cron expression.

2. Run daily

Run once per day at a time in 24-hour format (for example, 09:00).

3. Custom (Cron)

Use standard 5-field cron syntax:

# Every weekday at 9 AM
0 9 * * 1-5

# First day of every month at midnight
0 0 1 * *

# Every 30 minutes during business hours
*/30 9-17 * * 1-5

# Quarterly on the 1st at 6 AM
0 6 1 */3 *

Cron Format Reference

+-------------- minute (0 - 59)
| +------------ hour (0 - 23)
| | +---------- day of month (1 - 31)
| | | +-------- month (1 - 12)
| | | | +------ day of week (0 - 6) (Sunday=0)
| | | | |
* * * * *

Configuration

Setting	Description	Required
Schedule Type	Run at intervals, Run daily, or Custom (Cron) (default: Run daily)	Yes
Interval	How often, from the even intervals above (default: every hour)	With Run at intervals
Time (24-hour format)	Time of day (default: 09:00)	With Run daily
Cron Expression	Standard 5-field cron (default: 0 9 * * *)	With Custom (Cron)
Timezone	UTC, Eastern, Central, Pacific, London, or Tokyo (default: UTC)	Yes

A schedule runs only while its workflow is deployed; to stop it, undeploy the workflow. Deploying with an invalid cron, a daily time that is not HH:MM, or an interval not in the list is refused with the reason.

Outputs

Field	Type	Description
trigger_time	string	When the scheduler fired (ISO 8601, UTC)
local_time	string	trigger_time in the schedule's timezone
cron_expression	string	The cron the schedule runs on
timezone	string	The schedule's IANA timezone
next_execution	string	The schedule's next run, in its timezone
execution_context	object	day_of_week, date and time of local_time

Execution metadata also records success, trigger_type, cron, and timezone.

Timezone Configuration

Always specify the correct timezone for scheduled workflows. The schedule executes based on the configured timezone, which may differ from your local time or server time.

---

REST API Trigger

Expose a workflow as an authenticated REST API endpoint with role-based access control and input validation.

Use Cases

• Custom API endpoints for internal microservices
• Mobile and web application backends
• Third-party integration endpoints
• Synchronous request-response workflows

Configuration

A REST API workflow is called at POST /api/v1/workflows/<workflow id>/execute; its status (GET /api/v1/workflows/:id/status) gives the address.

Setting	Description	Required
HTTP Method	POST, GET, PUT, DELETE, PATCH, or Any Method (default: POST)	Yes
Require Authentication	Whether callers must be authenticated	No (default: true)
Allowed Roles	Roles permitted to call the endpoint: owner, admin, user, viewer (default: owner, admin, user)	No
Expected Inputs	Input field definitions with type and validation	No
Default Query Parameters	Default query parameters as JSON	No

Expected Inputs Schema

Define expected input fields with validation:

Property	Description
Name	Field name (e.g., userId)
Type	Data type: string, number, integer, boolean, array, object
Required	Whether the field is mandatory
Default	Default value if not provided
Description	Field description for API documentation

Outputs

Field	Type	Description
method	string	HTTP method
body	object	Request body
query	object	Query parameters
headers	object	Request headers
params	object	URL path parameters
user	object	Authenticated user info

Execution metadata also records success, authenticated, processedAt and requestId.

Response Handling

Use the webhook-response destination node to send structured responses back to the API caller. The workflow output returned by the webhook-response node becomes the HTTP response body.

---

Chat Trigger

Trigger workflows from chat and conversational interfaces with automatic conversation history management.

Use Cases

• Conversational AI assistants
• Customer support chatbots
• Interactive Q&A workflows
• Multi-turn dialogue systems

Configuration

Setting	Description	Required
Session ID Field	Input field name containing the session/conversation ID	No (default: sessionId)
Message Field	Input field name containing the message content	No (default: message)
Include History	Include previous messages in the conversation	No (default: true)
Max History Length	Maximum number of history messages to include (1-50)	No (default: 10)

Inputs

Field	Type	Required	Description
message	string	Yes	Chat message content
sessionId	string	No	Session/conversation identifier
userId	string	No	User identifier

Outputs

Field	Type	Description
message	string	Message content
sessionId	string	Session/conversation ID
history	array	Previous conversation messages
currentMessage	object	Current message: role, content, timestamp, userId, userName
userId	string	User identifier, when the input has one
userName	string	User name, when the input has one
channel	string	Channel the message came from (default default)
messageMetadata	object	timestamp, historyLength and isFirstMessage

---

Email Trigger

Start a workflow when new emails arrive in an IMAP mailbox. Deploy the workflow and it checks the mailbox every Poll Interval; each check passes on the matching emails that no earlier check returned, oldest first, up to Max Emails (the rest wait for the next check). A check that finds none runs nothing after the trigger. A draft run checks once.

Use Cases

• Automated email processing and routing
• Support ticket creation from incoming emails
• Invoice and attachment extraction
• Email-driven approval workflows

Configuration

Setting	Description	Required
IMAP Host	IMAP server hostname (e.g., imap.gmail.com)	Yes
Port	IMAP port (993 for SSL, 143 for non-SSL)	No (default: 993)
Use SSL	Connect using SSL/TLS	No (default: true)
Username	Email account username	Yes
Password	Email account password or app-specific password (encrypted)	Yes
Mailbox	Mailbox/folder to check	No (default: INBOX)
Search Criteria	Which emails a check considers	No (default: Unread)
Mark as Read	Mark the emails a check returns as read in the mailbox. Either way, an email is returned once	No (default: true)
Max Emails	Most new emails one check returns (1-100)	No (default: 10)
Poll Interval	How often the deployed workflow checks: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 or 30 minutes, or 1, 2, 3, 4, 6, 8 or 12 hours	Yes (default: 15 minutes)

Search Criteria Options

Value	Description
UNSEEN	Unread emails only
ALL	All emails
FLAGGED	Flagged/starred emails
RECENT	Recent emails
TODAY	Emails received today (since midnight UTC)

Outputs

Field	Type	Description
emails	array	Email objects with id (the IMAP UID), messageId, subject, from, to, date, bodyText, bodyHtml, attachments (each filename, path, contentType, size) and hasAttachments
count	number	Number of emails returned
mailbox	string	Mailbox name that was searched
searchCriteria	string	Search criteria used

Execution metadata also records host, mailbox and emailsFetched.

---

Form Trigger

Accept public form submissions with configurable fields, file uploads, reCAPTCHA protection, and rate limiting.

Use Cases

• Contact and inquiry forms
• File upload portals
• Survey and feedback collection
• Support ticket submission
• Application and registration workflows

Your form's address

Deploy the workflow: only a deployed workflow accepts submissions, with its deployed version's settings. The Form node's Configuration tab shows the address (Copy copies it):

POST /api/v1/forms/{workflowId}

Post the form as multipart/form-data (needed for file uploads) or application/json. Browsers on other sites may post to it.

Configuration

Setting	Description	Required
Form ID	Identifier passed to the workflow as formId	No (default: form)
Enable CAPTCHA	Require reCAPTCHA v3 verification	No (default: on)
reCAPTCHA Secret Key	Google reCAPTCHA v3 secret key (stored encrypted). While CAPTCHA is on, a form without it refuses every submission	With CAPTCHA
CAPTCHA Score Threshold	Minimum reCAPTCHA score (0.0-1.0)	No (default: 0.5)
Rate Limit (per hour)	Maximum submissions per hour from one IP address (1-1000)	No (default: 10)
Max File Size (MB)	Largest file accepted (1-100); up to 10 files and 50 fields per submission	No (default: 10)
Form Fields	The fields the form sends, each with a name, type and Required flag	No
Validation Rules	Extra checks per defined field (JSON)	No
Success Message	Returned to the submitter when the submission is accepted	No
Redirect URL	Returned to the submitter as redirect, for the page to go to	No

Fields and validation

Each submission is checked in the run against the form's fields; the result is the output's validation. The run goes ahead either way, so branch on validation.is_valid.

• Required fields must be present. A File Upload field is present when a file is uploaded under its name.
• Email, Number and Checkbox values are type-checked; other types (text, textarea, select, date, url, tel) are taken as sent.
• A submitted value with no field defined for it is kept and listed in validation.warnings.

Validation Rules are JSON keyed by field name, and apply to defined fields only: min_length, max_length, pattern (a regex the value must match from its start), and min_value / max_value for Number fields.

{"name": {"min_length": 2}, "age": {"min_value": 18, "max_value": 120}}

Spam protection

• CAPTCHA: Google reCAPTCHA v3 (score based, no puzzle). Send the token as the g-recaptcha-response field. Get keys from Google reCAPTCHA Admin.
• Honeypot: add a hidden input named _honeypot. A submission that fills it gets the success response but does not run.
• Rate limit: over the limit, the submitter gets 429 with a Retry-After header.

Responses to the submitter

Status	When
200	Accepted: {success, message, id} (the run's id), plus redirect when set. Validation happens in the run
400	The form could not be read, or CAPTCHA was missing or failed
402	A budget or the organization's credits are exhausted
404	No deployed workflow with a Form trigger at that address
409	The workflow is already running and does not take concurrent runs
429	Too many submissions from this address
500	CAPTCHA is on but no secret key is set, or the run could not start

Outputs

Field	Type	Description
formId	string	Form identifier
form_data	object	Submitted values, by field name (a submission over 5,000 characters is also stored, at form_data_s3_url)
files	array	Uploaded files: name, size, mime_type, fieldName, s3_url
validation	object	is_valid, errors, warnings, validated_field_count
submission_metadata	object	timestamp, ipAddress, userAgent, referrer

Execution metadata also records success, trigger_type, formId, field_count, file_count, and is_valid.

---

File Trigger

Start a workflow when files are added to or updated in an S3 data source. Deploy the workflow and it checks the location every Poll Interval; each check passes on the files modified since the previous check, oldest first. A check that finds none runs nothing after the trigger.

The first check records where the location stands and passes on nothing, so turning the trigger on does not replay files already there. Changing the bucket or prefix starts over the same way.

Use Cases

• Process new files dropped into a bucket prefix
• Monitor data landing zones for new CSV/JSON files
• Re-run a pipeline when a reference file is updated

Configuration

Setting	Description	Required
S3 Data Source	The S3 data source to watch (its bucket and credentials)	Yes
Prefix	Watch only keys under this prefix (empty = the whole bucket)	No
Filename Pattern (Regex)	Only files whose name matches this regular expression, e.g. .*\.csv$	No
Poll Interval	How often the deployed workflow checks: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 or 30 minutes, or 1, 2, 3, 4, 6, 8 or 12 hours	Yes (default: 15 minutes)

Outputs

Field	Type	Description
files	array	Files added or updated since the previous check, each with key, name, size, lastModified, etag and uri (s3://bucket/key)
count	number	Number of files
bucket	string	The data source's bucket
prefix	string	The watched prefix

To process each file, follow the trigger with a Loop over files and an S3 Source (download) or a parser.

---

RSS Feed Trigger

Start a workflow when an RSS or Atom feed has new items. Deploy the workflow and it checks the feed every Poll Interval; with Only New Items, each check passes on the items no earlier check returned. A check that finds none runs nothing after the trigger.

Use Cases

• News and content aggregation
• Blog post monitoring and notifications
• Competitor content tracking
• Automated content curation pipelines

Configuration

Setting	Description	Required
Feed URL	URL of the RSS or Atom feed	Yes
Poll Interval	How often the deployed workflow checks: 1, 2, 3, 4, 5, 6, 10, 12, 15, 20 or 30 minutes, or 1, 2, 3, 4, 6, 8 or 12 hours	Yes (default: 15 minutes)
Max Items	Most items one check reads from the feed (1-100)	No (default: 20)
Only New Items	Leave out items an earlier check returned	No (default: true)
Include Full Content	Include full article content when available	No (default: true)

Outputs

Field	Type	Description
items	array	Feed items with id, title, link, published, author, categories, summary, and content when Include Full Content is on
count	number	Number of items returned
feedTitle	string	Title of the feed
feedLink	string	The feed's website link
feedDescription	string	The feed's description
feedUrl	string	URL of the feed that was fetched

---

SSE Trigger

Trigger workflows when Server-Sent Events are received from an external SSE endpoint. Supports automatic reconnection and event type filtering.

Use Cases

• Real-time event stream processing
• Live data feed consumption
• Server push notification handling
• Streaming API integration

Configuration

Setting	Description	Required
SSE Endpoint URL	URL of the SSE endpoint to connect to	Yes
Event Types	Comma-separated event types to listen for (empty listens to all)	No
Headers	Custom headers for the SSE connection (key-value pairs)	No
Auto Reconnect	Automatically reconnect on connection loss	No (default: true)
Reconnect Delay (ms)	Delay before reconnection attempt	No (default: 3000)

Outputs

Field	Type	Description
eventType	string	SSE event type
data	any	Parsed event data (JSON if valid, otherwise string)
eventId	string	SSE event ID

---

Error Trigger

The Error trigger (error-trigger) starts a deployed workflow when a run of another workflow in your organization fails: its status is failed, error or timeout. Use it for one place that handles failures, such as logging them, opening an incident or alerting a team.

Configuration

Setting	Description	Required
Filter by Workflow	Start only for failed runs of these workflows, picked by name (none = any workflow in your organization). Through the API, filterByWorkflow is a list of workflow ids	No
Filter by Node Types	Start only when one of the run's failed nodes has one of these node types, such as code or llm (empty = any)	No
Include Stack Trace	Include the failed node's stack trace in the output	No (default: true)

• The filters are applied before a run starts: a failure they do not match starts nothing.
• The run is started as the user who deployed the workflow, who must be able to use the failed workflow. It appears in the workflow's executions with the trigger error.
• A workflow's own failed run never starts it.

Outputs

Field	Type	Description
error	object	message (the failed node's error, else the run's; it names the node as on the canvas, e.g. Node 'Code' failed: ...), type (the run's status: failed, error or timeout), timestamp, and stackTrace when included
workflow	object	The failed run: workflowId, workflowName, executionId
node	object	The failed node the trigger heard the run for: nodeId, nodeType, nodeName (the first failed node, or with Filter by Node Types the first of those types; empty when the run failed before any node ran)
context	object	runErrorMessage and failedNodes, every failed node of the run

---

Multi-Modal Input

Accept mixed media types as workflow input, including text, images, audio, and files in a single request.

Use Cases

• AI workflows requiring multiple input types (text + image)
• Document processing with mixed media
• Multi-format data ingestion pipelines
• Interactive applications with diverse input types

Configuration

Setting	Description	Required
Accepted Types	Array of accepted media types (text, image, audio, file)	No (default: all)
Max File Size (MB)	Maximum file size in megabytes (1-100)	No (default: 10)
Max Items	Maximum number of input items (1-50)	No (default: 10)

Outputs

Field	Type	Description
items	array	Each item with type, index, metadata and either content (text, or a URL) or path (binary content, stored for the run); an item that could not be processed has type error and the error
inputSummary	object	totalItems, byType (count per type) and acceptedTypes
textContent	string	All text items joined by new lines (null when there are none)
mediaItems	array	Every item that is not text

---

Event

The Event trigger (event) starts a deployed workflow when a platform event happens. A draft never starts on its own: deploy the workflow for its Event trigger to listen.

Configuration

Setting	Description	Required
Event Types	Workflow Completed, Workflow Failed, AI Model Deployed or Undeployed, Data Uploaded, Add-on Status Changed, Marketplace App Installed or Uninstalled	No (empty with no custom types = every event)
Custom Event Types	Your own event names, such as order.created, emitted through POST /api/v1/workflows/events	No
Source Workflow	Hear Workflow Completed and Workflow Failed only from this workflow's runs (Any workflow = every workflow you may use)	No

Run this workflow when another one ends. When a run ends, the platform emits workflow.completed (the run completed, completed with gaps, or ended in partial success) or workflow.failed (it failed, errored or timed out); a stopped or cancelled run emits nothing. To run workflow B whenever workflow A completes, give B an Event trigger with Event Types = Workflow Completed and Source Workflow = A, then deploy B. Each of A's completed runs, draft or deployed, starts a run of B.

• B's run is started as the user who deployed B, who must be able to use A; it appears in B's executions with the trigger event.
• Only workflows of A's organization hear A's runs, and a workflow's own runs never start it again.
• If B is already running at its concurrency limit, that event does not start it; the refusal is recorded on A's run.

Outputs

Field	Type	Description
event_type	string	The event, e.g. workflow.completed
event_data	object	The event's payload. For a run's end: workflow_id, workflow_name, execution_id, status, duration_ms, error_message (failed runs) and trigger_type
source	string	Who emitted it: workflow-controller for a run's end, otherwise what the emitter passed
emitted_at / received_at	string	When it was emitted and received (ISO 8601)

To be told about a run's end yourself rather than start a workflow, use an alert rule.

---

Queue

The Queue trigger (queue) runs the workflow once per message on a queue: an SQS queue, a RabbitMQ queue or a Kafka topic. Deploy the workflow and it consumes the queue; for each message it starts a run with the message as the trigger's output, and acknowledges the message when that run ends, whatever its outcome (SQS deletes it, RabbitMQ acks it, Kafka commits its offset once every earlier offset of its partition has ended too).

Configuration

Setting	Description	Required
Queue	Data source (an SQS, RabbitMQ or Kafka data source) or Add-on (a RabbitMQ or Kafka add-on)	Yes
Queue Data Source / Queue Add-on	Which one. An SQS data source is one queue (its queue URL)	Yes
Queue / Topic	The RabbitMQ queue or Kafka topic	RabbitMQ, Kafka
Kafka Consumer Group	Kafka only; default: one for this workflow	No

• The workflow's Max Concurrent Runs (Lifecycle tab; 1-10, default 1) caps how many messages' runs are in flight.
• While a message's run is in flight, SQS keeps it hidden from other consumers and RabbitMQ holds it unacked. A run the platform refuses to start (a spent budget, the run limit) keeps its message and is retried.
• Undeploying or restarting the workflow acknowledges nothing unfinished, so the queue hands those messages out again.
• The workflow's lifecycle policy must be Always On or Scheduled Window.
• A RabbitMQ queue that does not exist yet is waited for: the deployed workflow keeps checking, and starts consuming once the first publish (a RabbitMQ destination declares its queue) creates it. A broker restart is ridden out the same way.
• To put messages on the queue, send them to the queue itself: an SQS, RabbitMQ or Kafka destination node, or the producer's own client.

Outputs

Field	Type	Description
message	any	The message body: its JSON value, or its text
messageId	string	The broker's id (Kafka: topic:partition:offset)
attributes	object	SQS message attributes, RabbitMQ headers, or the Kafka key and headers
priority	number or null	The RabbitMQ message priority (a priority queue hands out higher priorities first)
source	string	sqs, rabbitmq or kafka
enqueued_at	string or null	When the message was put on the queue
processed_at	string	When its run started

---

Agent Trigger

The Agent trigger (agent-trigger) sends a message to an agent endpoint and captures the streamed response, which makes it useful for scheduled agent heartbeats and agent-driven workflows. Configure the agent URL, the message to send (sent exactly as written), a thread pattern that controls conversation grouping (daily, weekly, single, or per execution; default daily), and a response timeout (10-600 seconds, default 300). The trigger outputs the thread ID, the agent's response text, the tools it called, and the run duration.

---

Task Due

The Task Due trigger (task-due-trigger) fires when a platform task's due date is reached. You can filter which task firings start the workflow by subject kind, subject app, or assigned agent, and bound how many times a task must have fired before matching (for example, set a maximum fire count of 0 to fire only on a task's first activation). Leave all filters empty to match all due tasks within the workflow's tenant scope. The triggered workflow receives the full task object, including its description, subject reference, due date, recurrence, fire count, and tags.

---

Streaming Workflow Triggers

Streaming workflows use a separate trigger set from the batch palette. It includes the WebSocket trigger (websocket-trigger), which accepts real-time WebSocket connections for bidirectional audio and text streaming. See the streaming palette in the workflow builder for the full set.

---

Architecture Notes

Trigger Execution Model

Triggers are the entry point for every workflow execution. Each workflow has exactly one trigger node, and the trigger type determines how the workflow is invoked:

• Request-based triggers (webhook, REST API, chat, form, multi-modal input) are invoked through the platform backend when an HTTP request arrives at the appropriate endpoint.
• Queue triggers run a deployed workflow once per message on its SQS, RabbitMQ or Kafka queue.
• Schedule triggers run on the configured schedule. When the schedule fires, the workflow executes.
• Polling triggers (email, RSS, file) run a deployed workflow every Poll Interval; each check passes on only what is new, and a check with nothing new runs nothing after the trigger.
• Event-driven triggers (event, error, SSE, task due) react to events from the platform, other workflows, or external systems.

---

Common Patterns

Webhook Event Routing

Webhook Trigger (GitHub)
  -> Switch-Case (Route by event_type)
    -> [push] Process push event
    -> [pull_request] Process PR event
    -> [issues] Process issue event

Scheduled Batch Processing

Schedule Trigger (Daily at 2 AM)
  -> REST API Call (Fetch records)
  -> Loop (Process each record)
  -> MongoDB Destination (Update database)
  -> SMTP (Send completion report)

Form Submission Processing

Form Trigger (with CAPTCHA)
  -> Conditional (validation.is_valid)
    -> [true] MongoDB Destination (Store submission) -> SMTP (Notify the team)
    -> [false] Slack (Flag the rejected submission)

Centralized Error Handling

Error Trigger (Filter by Node Types: llm, http-request)
  -> Switch-Case (Route on error.type)
    -> [timeout] Alert on-call team
    -> [default] Log to monitoring system

---

Troubleshooting

Webhook Not Triggering

• Verify the webhook URL matches the pattern /api/v1/webhooks/{workflowId}
• Confirm the caller is authorized: a valid REST API key, or (for external signed services) an HMAC secret matching what the service is configured with
• Check that the workflow is deployed and active
• If using IP whitelisting, verify the sender IP is in the allowed range
• Review execution logs for signature verification failures

Schedule Not Running

• Verify the workflow is deployed
• Confirm timezone settings are correct for the intended execution time
• Review the workflow's run history in the Workflow Monitor
• Validate the cron expression syntax

REST API Returning Errors

• Verify authentication credentials and user roles match the allowedRoles configuration
• Check that the request body matches the expectedInputs schema
• Ensure the HTTP method matches the configured method
• Confirm the workflow is deployed and the call goes to POST /api/v1/workflows/<workflow id>/execute

Email Trigger Not Processing

• Test IMAP connectivity with the configured host and port
• Verify credentials (use app-specific passwords for Gmail)
• Confirm SSL settings match the server requirements
• Check that the search criteria matches available emails
• Verify the mailbox name is correct

---

Next Steps

• Configure workflow nodes
• Test your workflows
• Deploy to production
• See workflow examples