Migrating from Mailchimp Transactional (Mandrill) to Envello

If you're evaluating a move off Mandrill (Mailchimp Transactional), you already know your own reasons, so this guide skips the sales pitch and goes straight to the mapping. Check Mandrill's current plan requirements and pricing on their own site before you decide anything: this post covers the migration mechanics, not a comparison. The good news on effort: Mandrill's core sending API is a simple JSON POST, not a complex integration surface, so the change is fairly contained.

The sending call

Mandrill's messages/send endpoint takes a message object with html, text, subject, from_email, from_name, and a to array of {email, name, type} objects. The shape is close enough to Envello's from/to/subject/html/text fields that this is a mapping exercise, not a rewrite:

• from_email + from_name combine into Envello's single from field ("Name <email>" format)
• to array of objects becomes a plain array of addresses or a single string
• html and text map directly
• merge_vars (Mandrill's per-recipient template variables) don't have a direct Envello equivalent for batch personalization; render each recipient's content in your own code before sending if you were relying on this

Handling tags and metadata

Mandrill's tags array (used for filtering and reporting in their dashboard) doesn't have a direct field-for-field equivalent; if you rely on tags for internal categorization of sends, that logic needs to move into your own application (a database column tracking send category, for instance) rather than being passed through to the provider. Mandrill's metadata field, arbitrary key-value pairs attached to a send, is a similar story: track it your own side if you need it for later lookup, since it won't come back in Envello's delivery events unless you've stored it yourself.

Webhook event mapping

Mandrill's webhook events (send, deferral, hard_bounce, soft_bounce, open, click, spam, unsub, reject) map fairly directly onto Envello's event types (delivered, bounced, opened, clicked, complained), though the exact payload shape differs, so a straight pass-through handler won't work unchanged. Rewrite the handler to parse Envello's event structure and verify its HMAC-SHA256 signature (Mandrill doesn't sign webhooks the same way), rather than trying to make one handler serve both formats during a transition period.

What honestly doesn't carry over

Mandrill grew up alongside Mailchimp's marketing tooling, so some accounts lean on features (detailed engagement analytics tied into Mailchimp's broader reporting, certain template-management workflows) that don't have a one-to-one match in a focused transactional API like Envello's. If your usage is genuinely transactional, plain sends with logging and webhooks, this won't matter. If you were using Mandrill as a lighter-weight extension of your Mailchimp marketing setup, budget time to figure out which parts of that setup need a different home entirely.

Cutover

Same shape as any provider switch: add Envello's SPF, DKIM, and DMARC records alongside your existing ones, swap the API key, and route a small percentage of traffic first while watching Envello's log search (90 days of history by default) before widening the rollout.