~/email-for-developers providers ↗
hub · sdks

Email SDKs, by language.

Most email decisions come down to which SDK fits the language and runtime. This hub catalogs the SDK story per language, with editorial picks tied to the shared provider database. Type quality, edge-runtime support, idempotency-key exposure, and runtime ergonomics are the lenses that matter.

Looking for a framework integration instead? See the frameworks hub.

reading this as developers picking email infrastructure

The question here is which one a backend engineer would rather operate. That means SDK depth in the language already in use, whether a retry can safely be replayed, how much the event log tells you when a customer says the email never arrived, and whether the pricing curve stays sane as volume grows.

Applied to email API SDKs, that means weighing developer experience, SDK breadth, idempotency keys, and operating track record ahead of the rest, against password resets, receipts, and magic links shipped from application code.