SMTP vs email API: which should you use?

There are two ways to hand a message to an email provider for sending: an SMTP relay, or an HTTP email API. Both deliver the same email to the same inbox. The difference is in how your application talks to the provider, and that difference affects how much control you get and how much code you have to write.

Here is how the two compare and when to pick each.

What an SMTP relay is

SMTP (Simple Mail Transfer Protocol) is the standard protocol mail servers have used to move email since the 1980s. An SMTP relay is a server your application connects to, authenticates against, and hands a message to over that protocol. The relay then takes care of delivering it to the recipient.

Almost every language and framework already has an SMTP client built in or one library away. If your code, your CMS or your framework can already send mail, it speaks SMTP. Switching to a provider is often just a change of host, port and credentials.

A typical SMTP configuration looks like this:

Host:     smtp.your-provider.com
Port:     587
Username: your-api-key
Password: your-api-secret
Security: STARTTLS

Point your existing mailer at those settings and mail flows through the provider with no code changes.

What an HTTP email API is

An email API is a REST endpoint you send an HTTP request to, usually a POST with a JSON body describing the message. Instead of speaking a mail protocol, your application makes an ordinary web request, the same kind it already makes to every other service it integrates with.

A minimal send looks like this:

curl https://api.your-provider.com/v1/send \
  -H "Authorization: Bearer your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "from": "receipts@yourcompany.com",
    "to": "customer@example.com",
    "subject": "Your receipt",
    "html": "<p>Thanks for your order.</p>"
  }'

The response comes back as JSON, with a message id you can store and a clear status you can act on.

The trade-offs

SMTP is a drop-in. Its strength is compatibility. If you have an existing mailer, a framework's mail layer, or an off-the-shelf application, SMTP means no rewrite. It is the lowest-friction way to move onto a provider.

An API gives you richer control. Because you are sending structured JSON and getting structured responses, an API gives you things SMTP makes awkward:

• Structured errors. A failed POST returns a specific error you can branch on in code, rather than a numeric SMTP status you have to parse.
• Idempotency. You can attach an idempotency key so a retried request does not send the same email twice, which SMTP has no concept of.
• A message id on send. The response hands back an id you can log and later match against webhooks for delivery, opens and bounces.
• Attachments and metadata. Files, tags, template references and custom headers go in the request body as plain fields.
• Speed and scale. A single HTTPS request with connection reuse is often faster than an SMTP conversation's several round trips, which matters at volume.

The cost of the API is that it is provider-specific: the request format is not a universal standard the way SMTP is, so you write a small amount of integration code.

When to pick each

• Pick SMTP when you have an existing mailer or framework that already sends email, when you are integrating software you do not control, or when you just want mail flowing with minimal change.
• Pick an email API when you are building sending into an application from scratch, when you want idempotency, structured errors and webhooks, or when you are sending at a volume where throughput and precise control matter.

Many teams use both: SMTP for a legacy system or a third-party tool, and the API for their main application. For the detail on what the API can do, see the email API feature and the send API reference.

How Mailhuset handles it

Mailhuset does both. The REST API has official SDKs for Node, Python, PHP and Go, and on paid plans an SMTP relay at smtp.mailhuset.com takes mail from tools that only speak SMTP, under the same rules. Moving an app off SMTP is usually a few lines: replace the mailer call with one HTTPS request, keep your verified domain, and get signed webhooks reporting delivery. The same product covers transactional email, inbound and broadcasts, sends from the EU by default, and is priced as an allowance plus a per-thousand rate beyond it.

See the email API feature and the send API reference to get started.