Append mass-action items
Feed more targets into a run that is already going, without a second preview or consent token: the plan they execute is the one already approved, and appended items join the pacing chain BEHIND the tail so the schedule is not compressed.
Identities are payload-kind leads, the same shape a targets-scope create takes. Each one must carry at least one of ln_member_id, ln_id, sn_id, company_ln_id or nickname, which is what the run dedups on: a lead already enrolled comes back in skipped_duplicate_count instead of running twice, so re-sending an overlapping batch is safe. Up to 100 per call; repeat the call to keep a standing run fed.
The run has to be active: a paused one is 409 run_not_active (resume it first) and a stopped one is 409 too (create a new run). The canary gate still applies, so on a run whose gate is closed the appended items wait behind item 1.
Contract:
- MCP tool
append_mass_action_items, registry packagemcp.orchestration/mass_actions, mountorchestration.mass_actions. - Operation
action, response envelopeaction. - Flags: none.
Authorizations
Access token issued by gtm.service.id. Its access_identity claim carries team_sid, actor_sid and actor_type, and that team scope is authoritative.
Team scope for tokens that do not carry one. Ignored when the token already names a team.
Path Parameters
Mass-action sid (ma_ac_...).
18^ma_ac_Body
Request body of append_mass_action_items.
Payload-kind leads. Identity fields (ln_member_id / ln_id / sn_id / company_ln_id / nickname) are the dedup axis; any other key rides along as per-target extras the plan steps can read.
1 - 100 elements