An EU-hosted transactional email API, evaluating SendGrid?
A close sending-call shape, an honest answer on dynamic templates, and EU data residency, price stability, and long log retention as the default, not an enterprise add-on.
EU-hosted by default
API, database, logs, and backups run in the EU. A signed DPA ships on every plan, including free, no sales call required.
24-month price lock
Your tier price is fixed at signup. Any change after that gets 6 months' notice and a grandfathering option, published, not buried in a contract.
90-day log retention
Debug a bounce from three months ago, not three weeks ago. Free tier gets 7 days, Pro gets 90, Scale is configurable up to 365.
What actually moves, and what doesn't
Is the migration a codemod, like the Resend path?+
No. SendGrid's SDK shape (msg objects, personalizations arrays, template IDs) doesn't map onto Envello's API the way Resend's does, so there's no automated codemod. The sending call itself is close enough to be a find-and-replace: to, from, subject, text, and html map field for field.
What happens to dynamic templates?+
The honest answer: simple variable substitution ports directly. Templates using Handlebars-style {{#if}} or {{#each}} logic don't have a direct equivalent today, render that logic in your own application code instead, React Email is one option, and pass the rendered HTML string straight to Envello.
Do I need to change my error handling?+
Yes, this needs an actual look, not just a rename. SendGrid and Envello don't return the same error codes, so any retry or alerting logic branching on a specific SendGrid error needs updating to Envello's equivalents (rate_limited, recipient_suppressed, invalid_api_key).
Full walkthrough: Migrating from SendGrid to Envello