Email API: what it is and how to choose one

An email API is an HTTP interface to an email provider's sending infrastructure. The request is a JSON object describing a message (sender, recipients, content or a template reference), the immediate response is an ID for tracking it, and everything that happens afterward (delivery, bounce, open, complaint) comes back as events. It is the standard way applications send email today, and this guide covers how it works, what separates it from SMTP and from mailbox APIs like the Gmail API, and what to evaluate when picking one.

What an email API is and what it returns

The mechanics fit in one request. The application authenticates with an API key and POSTs a JSON body; the provider validates it, queues the message, signs it with the sending domain's DKIM key, and delivers it over SMTP to each recipient's mail server. The provider owns the hard part: warmed sending IPs, authentication, retries against greylisting, and bounce processing. A complete send through Lettr's API looks like this:

curl -X POST https://app.lettr.com/api/emails \
  -H "Authorization: Bearer lttr_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "orders@yourapp.com",
    "to": ["user@example.com"],
    "subject": "Your order shipped",
    "template_slug": "order-shipped",
    "substitution_data": { "tracking_number": "1Z999AA1" }
  }'

The response arrives in milliseconds:

{
  "request_id": "b7e2a1c4-93f0-4d2e-8a51-6c0f3d9e7b21",
  "accepted": 1,
  "rejected": 0
}

The request_id is the handle for everything that follows. A successful response means the message was accepted for sending, not that it was delivered; SendGrid's API makes the semantics explicit by returning 202 Accepted. The delivery outcome arrives asynchronously through webhooks, where the standard event set across providers is delivered, bounced, deferred, opened, clicked, complained, and unsubscribed. The journey of an email traces what happens between those two moments.

Email API vs. SMTP relay

The alternative transport for the same job is an SMTP relay: the application speaks the SMTP protocol to a provider host, which forwards the finished message onward. The relay reaches the same infrastructure, so deliverability is identical; the difference is what the protocol can express. SMTP moves a fully assembled message and nothing else, while an API accepts structured data, which is what makes server-hosted templates, idempotency keys, scheduled sending, and useful error responses possible. SMTP remains the right transport for legacy systems that only expose an SMTP settings screen; the SMTP vs. REST API guide covers the decision in detail.

Email API vs. mailbox APIs (Gmail API, Microsoft Graph)

A search for "email API" also surfaces the Gmail API and Microsoft Graph, and the naming hides a category difference. Those are mailbox APIs: programmatic access to one person's mailbox, authorized per user over OAuth. Google's own description is access to Gmail mailboxes for use cases like mail extraction, backup, and organization. Sending exists, but it sends as that user, from that mailbox, under that mailbox's limits.

The limits are the clearest evidence of intended scale. A Google Workspace account allows 2,000 messages a day, the Gmail API caps a message at 500 recipients and its quota arithmetic works out to roughly 60 sends a minute per user, and Exchange Online (which Microsoft Graph sends through) enforces 30 messages a minute and 10,000 recipients a day. Beyond volume, a mailbox API has no bounce webhooks, no suppression list, and no way to isolate the sending reputation from the rest of the mailbox. Mailbox APIs are the right tool for building an email client or automating a personal inbox; application email belongs on a transactional email API.

What "SMTP API" means

The term shows up with two meanings. In most current usage, a provider's "SMTP API" is simply its authenticated SMTP relay offered alongside the HTTP API, the same sending account reached over a different protocol. The second meaning is historical and literal: SendGrid's X-SMTPAPI header, a JSON object carried in an SMTP message's headers to express per-recipient substitutions, scheduling, and category tags over a protocol that has no fields for them. It still works and remains documented, but it is a workaround for SMTP's limits; the modern equivalent of everything it does is a JSON body on the HTTP endpoint.

How to choose an email API

Sending is the commodity; the operational surface around it is the product. Six criteria separate the providers in practice:

• Webhooks. Which events exist, and how failed deliveries retry. The event set is where analytics and suppression logic hang; a provider without a complaint event, for example, leaves spam reports invisible.
• Idempotency. A network timeout on a send leaves the outcome unknown, and a naive retry can email a customer twice. An idempotency key makes the retry safe (Resend, for instance, honors an Idempotency-Key header for 24 hours).
• Template hosting and language. Server-side templates mean copy changes without a deploy. The language's power varies widely, from bare variable substitution to conditionals, loops, and reusable snippets; SendGrid uses a subset of Handlebars, Lettr ships a full template language behind a visual editor.
• Analytics granularity and retention. Per-email event history versus aggregate counters, and for how long: Postmark keeps message activity 45 days by default, MailerSend's free tier keeps 24 hours, Lettr stores per-email statistics as a core feature. Retention limits how far back a delivery dispute can be investigated.
• Sandbox and onboarding friction. Amazon SES starts every account in a sandbox limited to 200 messages a day until production access is approved; other providers apply manual account review. Worth knowing before a launch deadline — if the sandbox is a blocker, the AWS SES alternatives comparison covers providers without one.
• Suppression handling and data residency. How bounces and complaints are suppressed and whether suppressions can be audited (Postmark, notably, never deletes a spam-complaint suppression), plus EU hosting where residency is a requirement (Mailgun runs a separate EU region).

A useful tiebreaker is whether the provider offers both the API and an SMTP relay on the same account, so a legacy CRM and a new serverless function share one suppression list and one set of analytics.

Free email API tiers in 2026

Most providers keep a free tier large enough to develop against and run a small product on. The figures below were checked in July 2026 and this is the most volatile corner of the market: SendGrid retired its free plan entirely in 2025, and MailerSend cut its from 3,000 emails to 500 the same year.

The full provider comparison covers paid pricing and the tradeoffs behind these numbers, and the free email API page details what Lettr's tier includes.

FAQ

Bottom line

An email API is a JSON endpoint in front of managed sending infrastructure: one POST to send, an ID back, and webhooks for the truth about delivery. Evaluate providers on the operational layer (webhooks, idempotency, templates, retention, suppressions) rather than the send call, and rule out mailbox APIs for anything an application sends at scale.

The fastest way to evaluate any of this is a real request. Create a free Lettr account (3,000 emails a month included), copy the curl example above with a real API key, and the first message with full per-email analytics takes about two minutes.