Trigger Nodes

Trigger nodes are only available for Action agents. They define how an autonomous flow is initiated -- the trigger node is always the first node in an action agent's journey. While Knowledge agents start when a user sends a message, Action agents start when a trigger fires.

For general information about Action agents and their trigger configuration, see Action Agents.

Schedule Trigger

Type: schedule_trigger

Starts the flow on a recurring schedule defined by a cron expression. The agent runs automatically at the specified times without any external input.

Properties

Property	Type	Description
`cronExpression`	string	Standard cron expression defining the schedule (e.g., `0 9 * * *` for daily at 9 AM)
`cronTimezone`	string	IANA timezone for the schedule (e.g., `America/New_York`, `Europe/London`)
`cronDescription`	string	Human-readable description of the schedule (e.g., "Every weekday at 9 AM EST")

Cron format

The expression follows standard five-field cron syntax:

minute  hour  day-of-month  month  day-of-week
  0       9       *           *        1-5

Common patterns:

Expression	Schedule
`0 9 * * *`	Every day at 9:00 AM
`0 9 * * 1-5`	Every weekday at 9:00 AM
`0 /4 * *`	Every 4 hours
`0 0 1 * *`	First day of every month at midnight
`/30 * * *`	Every 30 minutes

The timezone setting ensures the schedule runs at the correct local time regardless of where the server is hosted.

Use cases

Daily morning performance reports sent to Slack
Hourly ad spend pacing checks
Weekly campaign optimization runs every Monday at 8 AM

Webhook Trigger

Type: webhook_trigger

Starts the flow when an HTTP request is received at the agent's unique webhook URL. External systems can call this endpoint to trigger the agent with custom payload data.

Properties

Property	Type	Description
`webhookTriggerPath`	string	The unique path segment for this agent's webhook URL
`webhookTriggerMethod`	`POST` \| `PUT`	Accepted HTTP method
`webhookTriggerPayloadFields`	array	List of field names to extract from the request body into flow variables
`webhookSecret`	string	Optional shared secret for validating incoming requests

Webhook URL

Each agent gets a unique webhook URL in the format:

https://<ws-url>/webhooks/<webhookTriggerPath>

The URL is displayed in the agent's Triggers tab after you configure the webhook trigger node.

Payload extraction

Fields listed in webhookTriggerPayloadFields are extracted from the JSON request body and made available as flow variables with the same names. For example, if the payload is:

{
  "campaign_id": "abc123",
  "event": "budget_exceeded",
  "amount": 1500
}

And webhookTriggerPayloadFields includes campaign_id, event, and amount, then those three values are accessible as variables throughout the flow.

Request validation

When webhookSecret is set, incoming requests must include a matching signature header. Requests without a valid signature are rejected with a 401 response. This prevents unauthorized systems from triggering the agent.

Use cases

Respond to CRM events (new lead created, deal stage changed)
Process form submissions from external landing pages
React to payment events from Stripe or other payment processors
Trigger optimization runs when a platform sends a notification

Data Monitor

Type: data_monitor

Starts the flow when monitored data changes. The node polls a URL at a configured interval and fires the flow when it detects a change in the response.

Properties

Property	Type	Description
`monitorUrl`	string	The URL to poll for changes
`monitorInterval`	number	Polling interval in seconds
`monitorCondition`	string	Condition that determines when the data counts as "changed"
`monitorHeaders`	object	Custom HTTP headers to include in the polling request (e.g., API keys, authorization tokens)

How it works

The Data Monitor periodically fetches the configured URL and compares the response against previous results. When the monitorCondition is met -- typically when the response content differs from the last poll -- the agent flow is triggered. The response data is available as a flow variable for downstream nodes to process.

Polling interval

Set the interval based on how quickly you need to react. Shorter intervals (e.g., 60 seconds) catch changes faster but consume more resources. Longer intervals (e.g., 3600 seconds) are better for data that changes infrequently.

Authentication

Use monitorHeaders to pass authentication credentials to the polled endpoint. Common patterns include:

Authorization: Bearer <token> for OAuth-protected APIs
x-api-key: <key> for API-key-protected endpoints

Use cases

Monitor competitor pricing pages and trigger alerts when prices change
Track inventory levels on a supplier API and reorder when stock drops below a threshold
Watch a status page for outage notifications
Detect new entries in an external data feed

Logic & Flow Nodes Cross-Agent Nodes