List Condition Branches
Lists the branches of a condition step, in execution order.
How a condition step branches
A condition step (type: "conditional") holds an ordered list of branches. Each branch owns a
sub-sequence — the steps a lead walks once it matches — and the last entry is the Else branch,
which catches every lead no other branch matched.
Order is execution priority: lemlist tests the branches top to bottom and the first match wins.
The Else branch always runs last and is never part of that race.
A branch is addressed by its sequenceId, never by its position. A reorder moves positions around;
the sub-sequence id is what the runtime routes leads to, and what every branch endpoint takes as its
branchSequenceId. That same id is also the one you pass to
POST /sequences/{sequenceId}/steps to
put steps inside the branch.
Reading a branch
Thekey is the condition the step tests — every branch of a step shares it, so a branch never
carries a condition of its own. What differs from one branch to the next is the value it tests,
returned as structured parameters rather than as a raw Mongo selector:
selector comes back only when none of those could describe the branch — an unknown or hand-written
shape. Everything else is expressed as parameters you can send straight back to the write endpoints.
customValues is an array because a customLeadInfo branch may test several values: it matches
when any one of them does. The write endpoints currently take a single customValue; a branch
testing several values is built from the lemlist campaign editor.Names
name is the name someone gave the branch, and it is only present when someone did. lemlist labels
the unnamed branches “Branch 1”, “Branch 2”, … by rank, and the last one “Else” — those defaults are
display copy, not stored data, so this endpoint does not invent them for you.
Access
Reading branches is open to everyone. Writing them — add, rename, re-select, reorder, delete — is in closed beta and answers403 unless the beta is enabled for your team.
Editing a running campaign
Once leads have entered the campaign, lemlist locks the part of the tree they walk. Adding, removing and reordering branches, and changing what a branch tests, are then refused with409 SEQUENCE_BRANCH_CAMPAIGN_RUNNING — re-routing live leads would strand those already sent down
the old path.
Two things stay editable on a running campaign:
- renaming a branch, which never re-routes anyone;
- the
delayvalue of a lead-action condition (hasScore,aircallDone) — how long it waits, not what it waits for. ChangingdelayType, or anything else about the selector, still locks.
Authorizations
Basic authentication header of the form Basic <encoded-value>, where <encoded-value> is the base64-encoded string username:password.
Path Parameters
The unique identifier of the sequence holding the condition step
The unique identifier of the condition step, from GET /campaigns/{campaignId}/sequences
Response
The step's branches, ordered.
The branch's sub-sequence id, and its address on every branch endpoint. Pass it to POST /sequences/{sequenceId}/steps to add steps inside the branch.
Execution rank among the non-fallback branches, starting at 0. The first branch whose test matches takes the lead. Absent on the Else branch, which always runs last.
true on the Else branch - the one that catches every lead no other branch matched. Absent on the others.
The condition the step tests. Every branch of a step shares it: a branch never carries a condition of its own.
The branch's display name, present only when someone has set one. lemlist labels the unnamed ones "Branch 1", "Branch 2", … and "Else"; those defaults are not stored and are not returned here.
Length of the time window the condition waits on the lead's action, in days. Only on the lead-action conditions that store one.
How the condition waits: within branches once the window is over, waitUntil parks the lead until the action happens, with no time bound.
within, waitUntil hasScore only - how the lead's score is compared to scoreThreshold.
$gte, $lt hasScore only - the score this branch tests against.
hasEmailAddress only - the email statuses this branch matches.
deliverable, risky, undeliverable, unverified aircallDone only - the call-status keys this branch matches.
customLeadInfo only - the tested field, normalized: a lead variable reads back as variables.<name>, a contact field as fields.<name>. Every branch of the step tests the same field.
customLeadInfo only - how the field is compared to the tested values.
equal, contains, empty, notEmpty customLeadInfo only - every value this branch tests; the branch matches when any of them does. Empty for the empty and notEmpty operators.
The raw stored condition selector, as JSON. Returned only when none of the fields above could describe the branch.