The four commands are published in CLI stable 0.1.10. Their public API adapters await backend deployment. Package installation alone does not make these routes available. Product MCP activation tools remain pending.
/api/v1/organizations/{orgId}/workspaces/{wsId}/campaigns/{campaignId} and a scoped Developer API key. Tenant membership and campaign permissions are checked by the server.
Prepare a verified-member test
Read current readiness first. Test preparation requires connectorId, savedCampaignVersion and readinessVersion; recipientMemberId is optional. The target must be a verified workspace member, not an arbitrary prospect email address.
Use the prepared preview to review the sender, recipient, subject, body and consequence. Sending requires the exact returned confirmation together with the versions, sender and a body idempotencyKey. The global idempotency header does not replace this body key. The native durable SMTP receipt protects against duplicate sends; do not manufacture confirmation tokens or retry with changed payloads under the same key.
Prepare a launch
Launch preparation requires savedVersionId and readinessVersion. It returns the native confirmation; preparation itself does not launch or resume a campaign. The existing campaigns start action uses that confirmation and still checks audience, schedule, billing, sender and campaign readiness. If a saved version or readiness state changes, prepare again.
Handle refusals
Authentication and permission refusals retain their public status and error envelope. Malformed body types are rejected before activation work. Stale versions or mismatched confirmations require a fresh preparation; never bypass a blocked audience or sender check. See errors and idempotency.
The CLI guide shows dry-run examples. Canonical source contracts own the exact command metadata. The generated API reference will incorporate these operations with the backend release rather than present undeployed operations as live.
