Core difference
Brevo combines transactional sending, SMTP templates, senders, domains, webhooks, contact lists, campaigns, and blacklist concepts. MailChannels is built for platforms where many downstream senders share infrastructure and reputation. The migration should move send calls to MailChannels, but it should also map sender identity, domain authorization, sub-account boundaries, suppressions, and containment paths so one sender’s behavior does not become everyone’s delivery problem.Feature mapping
Send payload notes
Brevo’s transactional API and MailChannels both support API-based delivery, but their payloads and template assumptions differ.Template migration
Export Brevo SMTP templates and identify every application path that references a Brevo template ID. Replace those IDs with application-owned template names, files, or records. Convert Brevo-specific variables to the data shape your MailChannels send payload will provide.Suppression policy
Recommended defaults:Marketing migration
MailChannels Email API does not replace Brevo contact lists, segmentation, campaigns, or campaign analytics. Keep audience management and campaign scheduling in a separate system, and use MailChannels as the governed delivery layer for permission-based messages that should move through shared-sender controls.Cutover checklist
- Replace Brevo send endpoint and authentication.
- Move SMTP templates into application-owned storage.
- Convert template params into
dynamic_template_data. - Create and publish MailChannels DKIM records.
- Recreate transactional webhooks for MailChannels event payloads.
- Export or rebuild contact lists and campaign workflows externally.
- Split blocked and blacklisted contacts into explicit suppression policy.