One POST, one gate, one send that can't be lost
POST /v1/emails returns a 202 that means something: durably queued, safe to retry, traceable from admission to the receiving server's response.
A send call that holds up under failure
Email Fast is a transactional email API with a single write path. You call POST /v1/emails, and 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. Everything else on this page — batches, scheduling, streams, suppressions, validation — hangs off that one call and passes through that one gate.
How it works
| Surface | What you get |
|---|---|
POST /v1/emails | One message. idempotency_key makes retries safe; send_at schedules up to 30 days out; a scheduled send can be canceled before it leaves |
POST /v1/emails/batch | Up to 500 messages per call, with a per-item result for each |
| Streams | Separate transactional traffic from broadcasts, so one kind's volume never sits in front of the other |
GET /v1/messages/:id | The full timeline of any send: admission, render, queue, delivery events |
| Suppressions | Bounces, complaints, and unsubscribes enforced at admission — readable and manageable over the API |
POST /v1/validate | Catch undeliverable addresses before you spend a send on them |
Underneath all of it: 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 evidence
// POST /v1/emails
{
"to": "ada@example.com",
"subject": "Reset your password",
"html": "<p>Your reset link is inside.</p>",
"idempotency_key": "reset-8412"
}
// HTTP/1.1 202 Accepted
{ "id": "msg_01h9...", "status": "queued" }Replay that exact request — same idempotency_key — and you get the same msg_01h9... back, not a second email. Kill the process right after the 202 and the send still happens: it was on disk before we answered.
Honest limits
A 202 is admission, not delivery. Delivery is asynchronous; the outcome arrives on the message timeline and over webhooks. The caps are real: 500 per batch, 30 days for send_at — guardrails, not upsells. And during early access, live outbound delivery opens at launch; everything here runs today against sandbox keys.
Where to go next
Start with the developer overview or go straight to the API reference. Coming from another provider? Your existing SDK may already work — the comparison covers the differences that matter.
Questions, answered plainly
How do idempotency keys work?
Pass idempotency_key on any send. A retry with the same key returns the original message instead of creating a duplicate — per message, honored for 90 days. Crash mid-request, retry blindly, and you still send exactly once.
Can I schedule and cancel sends?
Yes. send_at schedules up to 30 days ahead, and a scheduled message can be canceled any time before it leaves. GET /v1/messages/:id shows exactly where it is.
What are the batch limits?
POST /v1/emails/batch takes up to 500 messages per call and returns a per-item result for each, so one bad address never fails the other 499.
How do I find out what happened to a message?
Every send has a timeline: GET /v1/messages/:id returns the full event history, and signed webhooks push the same events to your endpoint as they happen.
Can I try it without sending real email?
Yes — sandbox keys run this whole surface against the real pipeline with nothing leaving, free and unlimited on every plan.