hub · frameworks

Send email from your framework.

Framework integration is where SDK quality meets runtime reality. This hub catalogs the right send patterns, the common pitfalls, and the provider picks for popular web frameworks. Each page lists patterns to copy and mistakes to avoid.

Next.js

typescript

Server actions and route handlers are the natural send points. Edge-runtime support varies by provider SDK.

Nuxt

typescript

Nuxt server routes and Nitro handlers are the send points. Most provider SDKs work without modification.

Remix

typescript

Loaders and actions are the send points. Remix is comfortable with both Node and edge deploys.

SvelteKit

typescript

Form actions and server-only modules are the send points. Most Node SDKs work; edge support is provider-specific.

Django

python

Anymail is the canonical bridge. Most providers ship Anymail backends; pick a provider with a maintained backend rather than a raw SDK.

FastAPI

python

Async-first. Provider SDKs without async support need an httpx wrapper or a thread pool.

Ruby on Rails

ruby

Action Mailer is the canonical interface. Providers with a maintained Action Mailer adapter beat raw SDK use.

Laravel

php

Laravel Mail is the canonical interface. Providers with a maintained transport beat raw SDK use.

Looking for a language-level SDK comparison? See the SDK 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 sending email from a web framework, 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.