Resend vs SendGrid
SendGrid (now part of Twilio) is the incumbent of transactional email: it has been around since 2009, handles enormous volume, and its v3 Mail Send API covers nearly every feature a sender could ask for — including per-message metadata and scheduled sends. That maturity comes with a sprawling dashboard, IP-reputation management you may need to do yourself on shared pools, and a pricing ladder that can surprise you as volume grows. Resend is the opposite trade: a small, sharp API with excellent defaults, React Email templates, and a fast path from signup to first send, at the cost of fewer enterprise controls. On the message shape itself the two are nearly equivalent; SendGrid's extra metadata field support is the only structural difference the SDK has to reconcile.
Message field support
Field support as encoded in Email SDK's own adapter capability matrix — the same data the SDK uses to reject sends that would silently drop fields.
| Message field | Resend | SendGrid |
|---|---|---|
| CC recipients | ✓ | ✓ |
| BCC recipients | ✓ | ✓ |
| Reply-To address | ✓ | ✓ |
| Custom headers | ✓ | ✓ |
| Attachments | ✓ | ✓ |
| Tags | ✓ | ✓ |
| Metadata | — | ✓ |
| Scheduled sending (sendAt) | ✓ | ✓ |
Fallback compatibility
Failing over from SendGrid to Resend loses: metadata.
Same code, either provider
With Email SDK the send call is identical for both providers — only the adapter import changes:
import { createEmailClient } from "@opencoredev/email-sdk";
import { resend } from "@opencoredev/email-sdk/resend";
const client = createEmailClient({
adapters: [resend({ apiKey: process.env.RESEND_API_KEY! })],
});
await client.send({
from: "hello@yourdomain.com",
to: "user@example.com",
subject: "Welcome!",
html: "<p>It works.</p>",
});Or run both, with automatic fallback:
import { createEmailClient } from "@opencoredev/email-sdk";
import { resend } from "@opencoredev/email-sdk/resend";
import { sendgrid } from "@opencoredev/email-sdk/sendgrid";
const client = createEmailClient({
adapters: [
resend({ apiKey: process.env.RESEND_API_KEY! }),
sendgrid({ apiKey: process.env.SENDGRID_API_KEY! }),
],
defaultAdapter: "resend",
fallback: ["sendgrid"],
});FAQ
- Can I switch from Resend to SendGrid without rewriting my email code?
- Yes. With Email SDK both providers share one typed send() call and one message shape, so switching from Resend to SendGrid is a one-line adapter change plus an API key. The SDK fails fast if a message uses a field SendGrid does not support, so nothing is silently dropped.
- Which message fields does Resend support that SendGrid doesn't?
- SendGrid supports every message field that Resend supports, so nothing is lost moving a message from Resend to SendGrid.
- Can I use SendGrid as a fallback for Resend?
- Partially. Email SDK checks field support before every send: a fallback from Resend to SendGrid is rejected for messages using no fields, and from SendGrid to Resend for messages using metadata. Messages that avoid those fields fail over cleanly.
Adapter docs
Setup guides: Resend adapter and SendGrid adapter. Sending from your own domain? Verify SPF, DKIM, and DMARC with the free email DNS checker.