Supported step types
delayconditionwait_for_eventsend_email_templatesend_push_templatecontact_updateadd_to_audienceremove_from_audienceset_topic_subscription
Trigger shape
Common journey
- Trigger on
order.completed - Send a published email template
- Wait for
sendrealm.mail.open - If the event arrives, send a push template
- If it times out, add the contact to a follow-up audience
Publish requirements
- Exactly one trigger
- Reachable graph
- No cycles in v1
- Published template versions only
- Valid topic, audience, domain, and push app references
Runtime guarantees
- Automation runs are processed with at-least-once semantics.
- Step execution is protected with step-level idempotency keys so retries do not resend the same step when a send already succeeded.
wait_for_eventand timeout paths use run and wait locks to avoid double-resume races.- If a worker crashes, maintenance sweepers recover stale runs, replay due events, and advance expired waits.
Retry and timeout behavior
- Event processing retries use exponential backoff.
- Final failures move to the dead-letter queue for replay from backoffice tooling.
wait_for_eventtimeout handling is minute-level scheduler based, so timeout execution is near the requested delay but not hard real-time.- If a matching event arrives after the timeout branch already executed, the late event does not reopen that wait state or rerun the completed branch.
Billing and metering
- Usage can be metered by event ingest, automation runs, wait creation, template test sends, and delivery actions.
- Plan enforcement should be treated as separate from idempotency: a retried request may deduplicate, while accepted usage still counts against the relevant quota or metered line item.
Retention
- Runs default to 180 days of retention.
- Wait states default to 30 days of retention.
- Template and automation versions remain immutable, but project retention may archive old non-current versions that are no longer referenced by sends, runs, or broadcasts.