Email API vs SMTP: what each one costs you, and when to pick which

SMTP is the Simple Mail Transfer Protocol: the conversation two mail servers hold to move a message from one to the other, specified in RFC 5321 and in use since long before anything in your stack. When people say “we send over SMTP” they usually mean their application opens a socket to a relay and speaks that conversation itself, or has a library speak it for them.

The conversation looks roughly like this.

220 mail.example.net ESMTP readyEHLO acme.example250-mail.example.net250 STARTTLSSTARTTLS220 ready to start TLSEHLO acme.exampleAUTH LOGINMAIL FROM:<receipts@send.acme.example>RCPT TO:<ronald.williams@example.com>DATASubject: Your receipt....250 2.0.0 Ok: queued as 4B2Cb1

Notice how much of it is round trips. Greeting, capabilities, an upgrade to TLS as RFC 3207 describes, a second greeting because the first one happened in the clear, authentication, the envelope sender, each recipient, and only then the message itself. Every one of those is a turn, and every turn costs latency.

Notice also what comes back at the end: 250 2.0.0 Ok: queued as 4B2Cb1. That is the relay saying it has taken responsibility for the message. It is not a delivery, it is not an identifier you can query, and the string in it is the relay’s own queue id rather than anything your database knows about.

An HTTP email API is an endpoint you POST a message to. The message is JSON, the credential is a header, and the answer is a response body.

POST /emails HTTP/1.1Host: api.rasket.comAuthorization: Bearer $RASKET_API_KEYContent-Type: application/jsonUser-Agent: acme-billing/1.0Idempotency-Key: receipt-1042
{  "from": "Acme <receipts@send.acme.example>",  "to": ["ronald.williams@example.com"],  "subject": "Your receipt",  "html": "<p>Thanks for your order.</p>"}

HTTP/1.1 200 OKratelimit-limit: 10ratelimit-remaining: 9ratelimit-reset: 1
{ "id": "4ef9a417-02e9-4d39-ad75-9611e0fcc33c" }

One round trip, and an identifier that is yours to store. Every later event about this message — delivered, delayed, bounced, complained, opened, clicked — carries that same id, so correlating what happened with the order that caused it is a foreign key rather than a parsing exercise.

The headers are doing work too. Idempotency-Key makes a retry safe; the rate limit headers on the response say exactly where you are in the window, so a bulk job can pace itself rather than guess. Neither has an equivalent in the SMTP conversation, because SMTP is a transport and those are platform concerns.

The differences that actually change what you write. The last row is the one most teams decide on.

None of that makes SMTP a bad protocol. It is the protocol every one of these messages eventually travels over, including the ones sent through an API — the API is a front door, not a replacement. The question is only which side of that door your application stands on.

Three situations, and they are more common than the framing usually admits.

• You already run a mail server. If there is a relay inside your network that handles authentication, queueing and retries, pointing an application at it is less work than adding an external dependency and a new credential.
• The mail never leaves the building. Internal alerts to an internal relay have no deliverability problem to solve, because there is no external reputation involved and nobody is filtering them.
• It works and nobody asked you to change it. A functioning SMTP integration is not a bug. Migrate when you want something it cannot give you, not because the architecture diagram would look tidier.

There is a fourth: some hardware and some legacy software speak SMTP and nothing else. A scanner that emails a PDF, a monitoring appliance, an ERP module written two decades ago — none of those are going to learn HTTP because you would prefer it.

What none of those situations get is the layer above the transport. A relay will deliver the message and tell you it has taken it; it will not stop you mailing an address that bounced last week, will not sign the message with your domain unless you have configured that yourself, and will not tell you an hour later that the message was refused. Those are not protocol gaps — they are simply somebody else’s job, and with a bare relay that somebody is you.

The case for an API is not speed, though it usually is faster. It is that the things you need beyond delivery are on the other side of the socket, and with a plain SMTP relay they are yours to build.

• You need to know what happened. Not that the relay accepted the message — whether it arrived, bounced, was complained about or was opened. That reaches you as a signed event with the message id already attached; see the webhooks article for the shape of it.
• You need not to mail a dead address twice. A suppression list is state, and a transport has no state. Something has to remember that an address bounced, and enforce it on the next send.
• You need retries to be safe. A timed-out HTTP request can be repeated with the same idempotency key and recognised as a repeat. A timed-out SMTP conversation leaves you guessing whether the message was accepted.
• You are deploying somewhere that blocks the port. This is the mundane one, and it accounts for a great many migrations: it worked on a laptop and failed in a container.

The change is smaller than it sounds, because the fields have the same names. A message is still a from, a to, a subject and a body; what changes is the call that carries them.

• Find every place that opens a transport. In most codebases that is one module wrapped in a helper, and the helper is the seam.
• Replace the transport call with one HTTP call, keeping the helper’s signature. Now every caller is migrated without being touched.
• Store the returned id against whatever record caused the send. This is the new capability, and skipping it wastes most of the move.
• Add an idempotency key derived from that record, and point a webhook at an endpoint that writes events against it.
• Run both for a week on one low-stakes message type before switching the rest. Compare what each path can tell you about the same message an hour later.

Said plainly, because it decides this for some readers. Rasket is an HTTP API. There is no host to point a transport at, so an application built around one has to replace that call rather than repoint it.

For everyone else the replacement is usually an afternoon. The quickstart is a key, a domain and a first send, and the email API page covers what the platform does once the message is in. If you are working in Node, the migration path from a transport is spelled out in the Node.js article.