Skip to main content
Automations are DAG-based journeys with one trigger, reusable steps, and explicit branches.

Supported step types

  • delay
  • condition
  • wait_for_event
  • send_email_template
  • send_push_template
  • contact_update
  • add_to_audience
  • remove_from_audience
  • set_topic_subscription

Trigger shape

{
  "trigger": {
    "event_name": "order.completed",
    "filters": {
      "amount_gte": 1000
    }
  }
}

Common journey

  1. Trigger on order.completed
  2. Send a published email template
  3. Wait for sendrealm.mail.open
  4. If the event arrives, send a push template
  5. 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_event and 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_event timeout 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.