Email Fast Get a sandbox key
For developers

An email API you can run in five minutes — and verify forever

One clean REST API with durable, idempotent sends. SMTP if you'd rather not change code at all. A browser SDK for backend-free apps. And a test sandbox that runs the real pipeline dry.

Send in one call

import { EmailFast } from "@email-fast/nodejs";

const ef = new EmailFast({ apiKey: process.env.EMAILFAST_API_KEY, baseUrl: "https://api.emailfast.dev" });

await ef.send({
  to: "ada@example.com",
  subject: "Welcome!",
  html: "<h1>Hi {{name}}</h1>",
  data: { name: "Ada" },
  idempotency_key: "signup-42",
});

a 202 from the API means the send is committed to a durable, partitioned outbox before we answer — a crash can't lose it, and a retry with the same idempotency key can't double-send.

The parts you usually have to build yourself

Built inWhat it means for you
Idempotency keysRetry any request without double-sending — per message, honored for 90 days
Suppression managementBounces, complaints, and unsubscribes are enforced at admission; no ingress can skip them
Scheduling & batchsend_at up to 30 days out; batches of 500 with per-item results
Message timelineGET /v1/messages/:id returns the full event history for any send
Signed webhookswebhooks signed with timestamped HMAC-SHA256 (Stripe-style t=…,v1=…), with delivery hardened against server-side request forgery
Inbound emailReceive, parse, and route replies and inbound mail to your webhook, with SPF/DKIM/DMARC verdicts attached
Email validationPOST /v1/validate to catch bad addresses before you send

A sandbox that fakes nothing

sandbox keys (ef_sandbox_…) that run the real pipeline dry: real validation, real rendering, real events, a hosted capture inbox — and no email leaves.

curl https://api.emailfast.dev/v1/emails \
  -H "Authorization: Bearer ef_sandbox_..." \
  -d '{ "to": "test@example.com", "subject": "CI run", "html": "<p>ok</p>" }'

Point your CI at it. Assert on the event stream. Browse the captured message in the hosted inbox. Nothing leaves, and nothing is mocked.

Your existing code probably already works

SendGrid-, Mailgun-, and Postmark-compatible endpoints: point your existing SDK at a new base URL with a new key and keep your code — and if you'd rather not touch code at all, point your app's SMTP config at us: your API key is the SMTP password. See every migration path →

Frontend-only apps included

a browser SDK with EmailJS-compatible endpoints — the recipient always comes from the server-stored template, never from the request, so a public key in your frontend can't be abused to spam arbitrary addresses. How the browser SDK stays abuse-proof →

Built for the way you work now

SDKs for the browser (EmailJS-compatible), Node.js, Python, PHP, Go, and Ruby, plus a zero-dependency CLI and a published OpenAPI specification.

Your coding agent is a first-class citizen: markdown mirrors on every page (append .md), llms.txt and llms-full.txt, and an MCP server arming at launch. The agent guide →

And underneath it all

every send — REST, SMTP, browser SDK, compatibility endpoints, broadcasts, automations — passes through one admission gate: idempotency, suppression, quota, and content policy in a single checkpoint no ingress can skip — the property that makes everything above trustworthy. Email Fast runs its own mail transfer agent, warmup engine, reputation breaker, and per-tenant fair queue — the pipes are ours, not resold. How deliverability works →

Questions, answered plainly

What does the send API look like?

POST /v1/emails with to, subject, html, optional data merge variables, an optional idempotency_key, scheduling via send_at, and stream selection. A 202 response means the message is durably queued. Full reference in the docs.

Do you support batch sending and scheduling?

Yes — POST /v1/emails/batch accepts up to 500 messages with per-item results, and any send can be scheduled with send_at. Batches through the compatibility endpoints are transactionally atomic: a mid-batch failure rolls back every recipient so a retry can't double-send.

Can I keep using my SendGrid/Mailgun/Postmark SDK?

Yes: SendGrid-, Mailgun-, and Postmark-compatible endpoints: point your existing SDK at a new base URL with a new key and keep your code. See migration.

How do webhooks work?

Subscribe endpoints to email.sent, email.bounced, email.opened, email.clicked, email.complained, email.unsubscribed, and email.inbound — all of them webhooks signed with timestamped HMAC-SHA256 (Stripe-style t=…,v1=…), with delivery hardened against server-side request forgery.

How do I test without sending real email?

sandbox keys (ef_sandbox_…) that run the real pipeline dry: real validation, real rendering, real events, a hosted capture inbox — and no email leaves. Your test suite gets real behavior with zero risk — no third-party capture service required.

See it for yourself

Sandbox keys run the real pipeline dry — real validation, real events, a hosted inbox, no email sent. Early access is onboarding now.