Lytics Flows

Flows are Lytics customer journeys: a trigger segment, then delays, conditional splits, export steps, and exits. This skill takes a user from business intent ("I want a welcome email series") to a validated, created and activated flow, and covers day-to-day flow management (list, get, update, delete, state). Flows are the most complex Lytics object; follow the mode file rather than improvising payloads.

Before you start

• Credentials: references/auth.md.
• Request and response conventions (including where /v2 errors live: .errors[0].message): references/api.md.
• Every create, update, state change and delete goes through references/confirmation-gate.md. For state changes and deletes, spell out the consequence in the summary.
• Write conditions in FilterQL: references/filterql-grammar.md.

Gotchas

• Condition priority: lower number is checked first, first match wins. Give the most specific condition the smallest number. The fallback edge ("definition": "", "priority": 1) is taken out of the ordering and used only when nothing else matches.
• Do not build A/B splits. /v2/flow/ui ignores edge probability: an ab_test node saves without error and then sends every user down a single branch (the other branch is silently dropped). Tell the user to set the split up another way and verify it before the flow runs.
• DELETE /v2/flow/ui/{id} without a version permanently removes every version, including a running one. No soft delete, no undo. To remove one version use DELETE /v2/flow/ui/{id}/{version}.
• Write with the node/edge (TranslatedFlow) format. The steps / type_hint model is the internal /v2/flow representation; it is a read-only reference here, not a /v2/flow/ui payload (see manage.md).
• Units differ per field: trigger reentry_delay is in seconds (minimum 3600); delay node delay is in nanoseconds (24h = 86400000000000).
• Only one version can be running. Publishing a new version automatically sets the old one to draining.