Email for TypeScript apps. One client for transactional email with your existing provider account. Pick the providers you actually send through, add retries and fallback routes, catch unsupported fields before they are silently dropped, and keep every send observable.

• Adapters for 26 provider APIs plus SMTP, 27 adapters total, behind one normalized message
• Retries within an adapter, plus fallback routes across adapters
• Fail-fast field-support checks before a provider drops data
• Batch personalization with per-recipient variables, plus provider-side scheduled sends
• Observability hooks for logs, metrics, and traces
• Test adapters that never call real providers
• CLI for adapter discovery, doctor checks, and dry-run sends

Install

npm install @opencoredev/email-sdk

The SDK is server-side only and needs Node 20+ or Bun. Keep provider API keys out of client code.

Usage

import { createEmailClient } from "@opencoredev/email-sdk";
import { resend } from "@opencoredev/email-sdk/resend";

const email = createEmailClient({
  adapters: [resend({ apiKey: process.env.RESEND_API_KEY! })],
});

await email.send({
  from: "Acme <[email protected]>",
  to: "[email protected]",
  subject: "Welcome",
  html: "<p>It works.</p>",
});

Adapters

Resend, Postmark, SendGrid, AWS SES, Mailgun, Brevo, MailerSend, SparkPost, Mailchimp, Iterable, Loops, Plunk, Mailtrap, Cloudflare, Unosend, Scaleway, ZeptoMail, MailPace, Sequenzy, JetEmail, Lettermint, Lettr, Primitive, SendHeron, Helo, SMTP, and a testing adapter, each imported from its own entry point. New here? Start with resend for the fastest first send.

CLI

npx --package @opencoredev/email-sdk email-sdk doctor --adapter resend

Discover adapters, validate setup (doctor --live authenticates without sending), and run dry-run smoke sends from any environment.

Documentation

Full docs live at email-sdk.dev/docs. Good places to start:

• Production send pipeline
• Fallbacks and retries
• Field support

Telemetry

Email SDK collects anonymous usage analytics so we can see which adapters and CLI commands get used and how often sends succeed. The first run prints a notice with opt-out instructions.

What gets collected:

• Built-in adapter names (custom adapters are reported as custom) and CLI command names
• Logical send outcomes, adapter attempts, submitted and explicitly accepted message and recipient counts, uncertain outcomes, error codes, and send duration
• Total recipient counts (to + cc + bcc) and whether a message includes attachments (a boolean only, never the files themselves)
• Whether scheduling was requested
• SDK version, OS, Node.js version, whether the run happens in CI (and which CI provider), and whether usage comes from the library or the bundled CLI
• Redacted error reports: the error type, the Email SDK error code, and stack traces with file paths reduced to package-relative names. Error messages are scrubbed of email addresses, URLs, quoted text, long tokens, and home directories before upload.

Provider acceptance is not proof of delivery, and telemetry is best-effort, so these counts describe observed SDK usage, not every email sent. See telemetry for counting rules.

Everything is tied to a random anonymous ID stored in ~/.config/email-sdk/telemetry.json. Email content, subjects, addresses, headers, attachments, API keys, and any other message data are never collected.

Opt out at any time with an environment variable:

export EMAIL_SDK_TELEMETRY=0   # or DO_NOT_TRACK=1

or per client in code:

const client = createEmailClient({ adapters: [resend({ apiKey })], telemetry: false });

Telemetry is also disabled automatically when NODE_ENV=test.

Sponsors

Email SDK is supported by companies that help keep provider integrations practical and maintained. Want your logo here? Become a sponsor →

Star History

_{MIT License · Built by @leodev}