Move enrollments to another sequence
Moves up to 500 contacts from their current sequence into sequence. For each id, the contact is enrolled in the target first and the original enrollment is finished only if that worked, so nobody is left out of both. Moved contacts start the target sequence at its first step.
The new enrollment goes through every check a new enrollment does: the suppression list, the target’s rules of engagement and per-owner throttles, and the one-live-enrollment rule. If one refuses, the contact stays where they were and the id is listed in failed with the reason, such as Contact is already enrolled in this sequence. If a rule holds the new enrollment for approval, the move still goes ahead: the contact waits for approval in the target and the original is finished. If the target sequence is off, the new enrollment waits in pending until it is turned on. An unknown target fails every id with Sequence not found rather than failing the request.
The new enrollments are owned by user_id, not by their previous owners. To keep ownership, move each owner’s enrollments with that owner as user_id, or reassign them in bulk afterwards. note is accepted but not stored.
The ids are processed one at a time inside the request. A very large move can outlast the 55-second request timeout; a 504 then means moves may still be completing, so list the enrollments before you retry. Counts toward the Sequencer writes rate limit.
What the target can refuse
The new enrollment goes through every check any enrollment does. When one refuses, the contact stays where they were and the id is listed underfailed:
- If a rule holds the new enrollment for approval, the contact waits for approval in the target, and the original is finished.
- If the target sequence is off, the new enrollment waits in
pendinguntil it is turned on, and the original is finished.
Large moves
The ids are processed one at a time inside the request, and one failure does not stop the rest. A very large move can outlast the 55-second request timeout: a504 then means moves may still be completing. List the enrollments in both sequences before you retry, or move in smaller batches. note is accepted but not stored.Authorizations
Team-scoped API key generated in the Salesfinity dashboard under Settings → Connections → API & Webhooks. A missing or invalid key returns HTTP 403.
Headers
Makes this write safe to retry. Send a unique value, such as a UUID, and send the same value again when you retry the same request. A retry with the same key and the same request (method, path including the query string, and JSON body) returns the original successful response without acting twice. The same key with a different body or path returns 409, and so does a retry while the first request is still running; that one is safe to repeat after a moment. A request that fails frees its key, so a retry runs the write again: after a 5xx on a create, confirm with a GET before retrying. Keys are kept for 24 hours and are scoped to your team.
Body
The team member this call acts as. Must be an active member of the team the API key belongs to.
"507f1f77bcf86cd799439011"
Enrollment ids, 1 to 500.
500The sequence to move them into. Each contact is enrolled there first, at its first step, and finished in the original only if that succeeds. The new enrollments are owned by user_id.
Accepted but not stored.
500Response
How many succeeded, and why each of the others did not. Returned even when every id failed.
The outcome of a bulk enrollment action. The ids are processed one at a time, in the order sent, and one failure does not stop the rest.