Goal
Operate consent-backed broadcast mail without mixing it with application-triggered transactional traffic.Prerequisites
- A verified sender domain
- An active template
- 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 audience and import between 1 and 10,000 normalized, consent-evidenced members per request.
3
Create a draft campaign with an audience, template, optional pinned version, and verified sender.
4
Send the draft once, then inspect its batch, recipient items, events, and webhook deliveries.
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
Campaign lifecycle
- Member states include subscribed, unsubscribed, complained, and hard_bounced.
- Campaign states include draft, processing, queued, completed, and failed.
- 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.