Zintara campaign API lifecycle: validate before changing sending state

Define the decision

A campaign record does not establish a complete sending workflow. The reviewed handlers expose campaign, step, account and enrollment operations, each with its own validation. Treat activation as a deliberate release after configuration review.

Work through the procedure

1. Create and inspect the campaign with an appropriate campaigns scope.
2. Configure the supported sequence, schedule and mailbox selection.
3. Enroll only the reviewed lead IDs rather than a broad all flag.
4. Verify stop behavior, capacity and a controlled end-to-end test.
5. Change sending state only after an accountable release decision.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Lifecycle checklist: draft record → sequence checked → selected mailboxes verified → intended leads enrolled → schedule and exclusions reviewed → activation approved
Recovery note: deleting a campaign is not a recoverable archive.

Read the result

The sequence prevents a partially configured campaign from becoming an accidental production send. Contact state and enrollment state remain separate: an active campaign can contain ineligible or paused contacts.

Check before moving on

1. Use the returned identifiers instead of guessing them.
2. Inspect current state before resuming a paused enrollment.

Limits and next action

This guide is not an automatic activation script. Campaign writes can lead to real messages, so integrations need a clear release boundary and uncertain-attempt recovery.

Source: Zintara implementation and product context