Goal
Operate consent-backed broadcast mail without mixing it with application-triggered transactional traffic.Prerequisites
- An explicit brand and audience in the selected environment
- A verified sender domain for Live
- A saved template or a campaign preset
- Recipient consent source and timestamp evidence
Workflow
1
Use the protected transactional and broadcast streams, or create a custom stream of either type.
2
Create an explicit brand, then an audience with brandId, and import between 1 and 10,000 normalized, consent-evidenced members per request.
3
Choose an audience and optional segment, select a template or newsletter preset, then edit the campaign copy.
4
Save, preview both A/B variants if enabled, optionally send an untracked test, then send now or schedule.
Guided campaign drafts
- Each campaign owns its content snapshot. Editing it does not change a shared template. Existing template/version API inputs remain supported.
- Draft updates use PUT /mail/campaigns/{id} with the complete draft and its revision. A stale revision returns 409; reload before deciding how to merge your edits.
- Preview and test endpoints accept data and variant (a or b); tests also accept to. Pass revision when sending or scheduling to protect the content you reviewed.
- Scheduling accepts sendAt between one minute and one year ahead. Consent and suppressions are checked again during dispatch.
- The visual editor can insert public PNG, JPEG, or GIF assets up to 5 MB after processing and a clean malware scan. URLs include the immutable version. Existing Assets quotas and policies apply.
- A/B campaigns use a deterministic audience split between 10 and 90 percent. Sent and scheduled content is locked.
Traffic isolation
- Transactional streams are for user or application-triggered messages.
- Broadcast streams are for one-to-many communication and require unsubscribe behavior.
- The built-in transactional and broadcast streams are protected; custom streams retain the policy of their selected type.
Consent-backed audience import
Create and preview through the SDK
Use the audience created above and a client authenticated in the same environment. Creating and previewing a draft does not send it. A campaign test uses real delivery with live credentials; use Test for simulation. Review the spending estimate before submitting send or schedule.Campaign lifecycle
- Member states are pending_confirmation, subscribed, unsubscribed, complained, and hard_bounced. Pending members cannot receive campaigns until confirmed.
- Campaign states are draft, scheduled, processing, queued, completed, failed, and blocked. A billing-blocked campaign requires a fresh approved send action.
- A queued campaign references the resulting batch for recipient-level inspection.
- Campaign delivery uses the broadcast stream, campaign tags, list-unsubscribe behavior, and deterministic member idempotency keys.
Expected result
Only sendable, consented members enter a broadcast batch with deterministic idempotency and unsubscribe behavior.
Common failures
Related guides
Templates and OTP
Create versioned templates, preview and test them, send from a template, and use the built-in one-time-code challenge flow.
Events, webhooks, and timelines
List mail events, inspect per-message timelines, subscribe webhooks, rotate secrets, retry deliveries, and verify webhook signatures.
Bounces, suppressions, and reputation
Handle hard and soft bounces, workspace-scoped suppressions, sending limits, warmup stage, domain reputation, and reputation events.
Brands and shared contacts
Create explicit sending identities and share contact profiles within a brand while keeping audience consent independent.
Subscriber consent and imports
Preview imports row by row, preserve consent evidence and use double opt-in before marketing delivery.
Mail spending controls
Inspect recipient allowance and reserve capped Mail-only prepaid credit without automatic additional spending.