Agent-readable docs index: /docs/llms.txt. Full docs in one file: /docs/llms-full.txt. Download /docs/docs.zip to grep all markdown files locally.

Configure workflow steps, waits and decisions

A workflow graph connects named steps to outcomes. Ordinary actions use next; a condition uses yes and no; wait-for-event uses event and timeout; multiple-choice branches use configured case IDs and otherwise.

Messaging actions

Supported sends: email, SMS, WhatsApp, and Smart Channel. Configuration can include template_id, sender_id, subject, body, variables, whatsapp_connection_id, and sms_sender_id depending on the channel.
Smart Channel uses an ordered priority and a channel-specific channels object. For example, WhatsApp → Email → SMS selects the first eligible channel, with its own sender and content. Sender readiness, suppression, consent, provider requirements, and wallet reservations remain enforced.

Waits and time

  • Delay: an amount with unit of minutes, hours, or days.
  • Wait until: an absolute at, a time, or a contact field with offset_days.
  • Wait for event: a named event and timeout_hours; Event received continues immediately for the same contact before the deadline, while Time ran out continues when the deadline passes without it.
Date triggers use fields such as created_at or custom.birthday, offsets, time, repeat mode, and fixed/contact timezone mode. Birthday repeats yearly; February 29 birthdays use February 28 in non-leap years. Missing/invalid contact timezones fall back to the automation timezone.

Conditions and branches

Conditions are Boolean decisions. Rules use the segment-style all/any structure and can also reference event properties, event history, and segment membership. Connect both Yes and No paths deliberately.
Multiple-choice branches suit more than two outcomes. Add an Otherwise path when you need behavior for contacts that match none of the named cases.

Contact changes

Supported actions: update contact attributes/increments, set custom field, add/remove tag, and add/remove list. Use workspace-owned target lists and supported values.
List actions reflect the current primary-list model. Add to list copies the contact into the target list, retaining the source and execution history; the copy needs a phone or email. Remove from list moves the executing contact to Unlisted Contacts when its primary list matches. It does not delete another contact or its history.

Webhooks, goals and exit

A webhook step uses an existing workspace endpoint and configured payload. Outbound workflow requests have a stable idempotency key; receivers should deduplicate retries. A goal or exit step ends the applicable path according to the workflow configuration.
Checkpointing records side effects. After a restart, due waits resume and unfinished work can recover without intentionally recreating a provider-accepted send. Reconcile ambiguous acceptance before authorizing another delivery.
Next: connect application events or return to automation lifecycle.
Test mode does not mutate contacts. A simulated add-tag step will not make a later real-data condition see that tag during the same simulation.