How much vendor lock-in does an email API actually create?

The honest answer: less lock-in than a database or auth provider creates, but not zero. It's worth being specific about which parts actually create switching cost, rather than treating the whole category as either "totally fine, swap anytime" or "a trap."

What's genuinely easy to leave

The send call itself. Most transactional email APIs converge on a similar shape (from, to, subject, html/text), so the actual sending code is rarely more than a day of work to swap, as the migration guides for Resend, SendGrid, Postmark, and Mailgun on this blog show in detail. If your integration is just "call an API to send an email," you're not locked in by the API surface.

What actually creates switching cost

• Log and delivery history: once you switch, your old provider's log data usually doesn't come with you. If you need historical delivery data for compliance or debugging, export it before you migrate, not after
• Server-side templates with provider-specific logic: dynamic templates using a provider's own templating language (Handlebars-style loops and conditionals) need manual rework, not a mechanical swap
• Webhook consumers built around a provider's specific event shape and error codes
• Deliverability reputation: warmup and sending history reset with a new provider's IPs, even if the API swap itself is trivial

The practical takeaway

Design for the switching cost that's actually real rather than either ignoring it or over-engineering an abstraction layer you don't need. Keep templates simple where you can, export logs periodically if retention matters to you long-term, and don't assume a provider's specific error codes are stable enough to hard-code deep into your error-handling logic.