Series

A series sends dated emails to a whole audience at once — a launch, a seasonal campaign, an onboarding calendar everyone walks together. See how a series works for the concept.

Why a family of its own

A series is not a separate object: it is a sequence whose version carries triggerType: "fixed_date". These routes exist because that one difference changes what a call needs to carry — a start date and an audience — and because POST /api/v1/sequences refuses fixed_date for exactly that reason: half a series is an unpublishable series. So this family covers the series as a whole: creating one, reading its calendar, moving it, deleting it.

What is NOT here, and where it lives

The steps. Nodes, wires, versions and publishing are identical on a series, and they stay on the Sequences API:
To do thisUse
Open a draft versionPOST /api/v1/sequences/{id}/versions
Add an email step, a wait, a tag, a webhookPOST /api/v1/sequences/{id}/versions/{versionId}/nodes
Set a step's send timePATCH …/nodes/{nodeId} with sendTimeMinutes
Wire two stepsPOST …/edges
PublishPOST …/versions/{versionId}/publish
Duplicating those eighteen routes under a second prefix would have made two surfaces that drift apart at the first correction. A series id is a sequence id: pass it straight to those routes.

The two fields that make a series

Both live on the version, and both read back on GET /api/v1/sequences/{id}/versions:
FieldWhat it is
startsAtThe moment day 1 is measured from. No step carries a date — they all count from here, which is why moving this one value moves the whole series
sendTimeMinutesOn a step: the local time of day, in minutes from midnight (540 = 09:00). null means the step goes out as soon as the wait before it has elapsed
The duration between two steps is a wait block, exactly as in a sequence — not a field on the send.
A series enrols nobody. GET /api/v1/sequences/{id}/enrollments answers with an empty list on a series, and that is correct rather than a bug: there is no journey to walk.