SMTP vs REST email API explained

You wired up SMTP to send a confirmation email, it worked on your laptop, then it silently failed the moment you deployed to a cloud server. Or you got sending working and then realized you also need to read replies, so now you’re learning IMAP too. SMTP and IMAP are protocols from the 1980s and 1990s. They move bytes, but they hand you none of the structure a modern app expects.

A REST email API sits one layer up. You make HTTPS calls, get JSON back, and the same integration sends and reads mail across Gmail, Outlook, and any IMAP mailbox. This page compares the two honestly, including the cases where plain SMTP is still the right call.

What is the difference between SMTP and a REST email API?

SMTP is a transport protocol that only sends mail. It speaks over TCP, has no concept of reading an inbox, returns numeric reply codes instead of JSON, and leaves authentication, retries, and threading to you. A REST email API wraps sending and reading behind HTTPS endpoints, returns structured JSON, and handles OAuth, so one integration covers the full message lifecycle.

The split matters because real apps rarely just fire one-way mail. SMTP, defined in RFC 5321, handles the outbound hop and stops there. To read replies you add IMAP, a second protocol with its own connection, auth, and folder model. A REST layer collapses both into one HTTPS surface. A single POST sends, a single GET lists messages, and the response shape stays identical whether the mailbox is Google, Microsoft, or a self-hosted Dovecot server. You write one parser instead of three.

How do I send email using a REST API in Node.js?

Send a POST to /v3/grants/{grant_id}/messages/send with a JSON body containing to, subject, and body. The endpoint authenticates with a bearer token, delivers through the connected provider’s own infrastructure, and returns the sent message as JSON. There’s no SMTP handshake, no port to open, and no MIME string to assemble by hand.

The call below sends a single message from a connected account. The grant ID identifies which mailbox sends the mail, and the API routes it through that provider’s outbound servers, so deliverability inherits the provider’s reputation instead of a raw SMTP relay you’d have to warm up yourself. The same endpoint covers all supported providers.

Node.js SDKRequest

import Nylas from "nylas";

const nylas = new Nylas({ apiKey: "<NYLAS_API_KEY>" });

const sent = await nylas.messages.send({
  identifier: "<NYLAS_GRANT_ID>",
  requestBody: {
    to: [{ name: "Leyah Miller", email: "[email protected]" }],
    subject: "Your account is ready",
    body: "Welcome aboard. Your workspace is set up and waiting.",
  },
});

console.log(sent.data.id);

curl --request POST \
  --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages/send' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>' \
  --header 'Content-Type: application/json' \
  --data '{
    "to": [{ "name": "Leyah Miller", "email": "[email protected]" }],
    "subject": "Your account is ready",
    "body": "Welcome aboard. Your workspace is set up and waiting."
  }'

Why are SMTP ports 25 and 587 blocked on cloud servers?

Most cloud providers block outbound port 25 by default, and many throttle or block 587, to stop compromised instances from sending spam. AWS EC2 blocks port 25 on every new account until you file a request, and Google Compute Engine blocks it permanently with no exception. This is the failure that breaks SMTP deployments that worked fine in local testing.

The standard SMTP ports each carry baggage. Port 25 is the original server-to-server relay port and the one cloud platforms lock down hardest, since open relays are a spam vector. Port 587 is the modern submission port with STARTTLS, and 465 carries implicit TLS. Even when a port is technically open, a fresh IP has zero sending reputation, so mail lands in spam until you warm it. A REST email API sidesteps all of this: calls go over HTTPS on port 443, which is never blocked, and delivery rides the connected provider’s warmed infrastructure. Google documents the permanent port 25 block in its Compute Engine guides.

Which email API supports both sending and parsing in one integration?

A unified REST email API like the Nylas Email API sends and reads through the same grant and the same JSON schema. You send with POST /v3/grants/{grant_id}/messages/send and read with GET /v3/grants/{grant_id}/messages, both over HTTPS, across Gmail, Microsoft 365, Yahoo, iCloud, Exchange, and any IMAP server, so one integration covers the full inbound and outbound flow.

Threading is where the unified model earns its keep. To keep a reply in the same conversation, pass reply_to_message_id on the send call, and the API sets the In-Reply-To and References headers correctly for the provider. Reading back, every message carries a thread_id, so you group conversations without parsing raw headers yourself. Filtering uses the same surface: GET /v3/grants/{grant_id}/messages accepts subject, from, unread, received_after, and thread_id as query parameters. The list messages reference documents all of them.

The request below lists the 20 most recent unread messages from a connected inbox. It’s the read half of the integration, the part SMTP can’t do at all, and it returns the same JSON shape regardless of provider, so a Gmail mailbox and an Exchange mailbox parse identically.

Request

curl --request GET \
  --url 'https://api.us.nylas.com/v3/grants/<NYLAS_GRANT_ID>/messages?unread=true&limit=20' \
  --header 'Authorization: Bearer <NYLAS_API_KEY>'

SMTP vs REST email API comparison

The table below compares plain SMTP (plus IMAP for reading) against a REST email API across the dimensions that actually decide an integration: ports, auth, direction, and threading. SMTP wins on simplicity for one specific job; the API wins everywhere the app needs structure or two-way mail.

Dimension	SMTP + IMAP	REST email API (unified)
Direction	SMTP sends only; IMAP reads	Send and read in one integration
Transport	TCP ports 25 / 587 / 465 / 143 / 993	HTTPS on 443, never blocked
Cloud port blocks	Port 25 blocked on AWS and GCP by default	None, runs over 443
Auth	Per-mailbox SMTP/IMAP credentials or app passwords	OAuth handled through /v3/connect/auth
Response format	Numeric reply codes	Structured JSON
Threading	Set In-Reply-To headers by hand	Pass reply_to_message_id, get thread_id back
Multi-provider	Per-provider host, port, and quirks	One schema for Gmail, Outlook, iCloud, IMAP

New to Nylas? Start with the quickstart guide to set up your app and connect a test account before continuing here.

How does authentication compare between SMTP and an email API?

SMTP authenticates per mailbox with a username and password or an app-specific password, sent on every connection. A REST email API uses OAuth: the user approves access once through a provider consent screen, and your app holds a token instead of their password. Gmail and Microsoft both deprecated basic auth, so OAuth is the only path for those providers.

The credential model is the real divider. With SMTP you store and rotate one secret per mailbox, and a leaked password exposes the full account. OAuth scopes access to email only, and the user can revoke it without changing their password. The API runs the consent flow through /v3/connect/auth, returns an authorization code, and exchanges it for a grant that every later call references. Microsoft turned off basic authentication for Exchange Online on October 1, 2022, which broke a wave of SMTP integrations overnight. Building on OAuth from the start avoids that class of breakage entirely.

When is plain SMTP the right choice?

Plain SMTP is the right choice when you only send, the volume is low, and you never read replies. A status cron job, a single-server contact form, or a script that emails one alerts address has no need for OAuth, JSON parsing, or a managed API. With port 587 open and one mailbox, SMTP through Nodemailer is a few lines.

The case for SMTP collapses the moment requirements grow. The second you need to read replies, thread conversations, support more than one provider, or run on a cloud host with port 25 blocked, the protocol-level work compounds fast. At that point a REST email API replaces SMTP, IMAP, OAuth handling, and per-provider quirks with one HTTPS surface. Be honest about which side of that line your app sits on before you build. If it’s genuinely one-way and one-mailbox, SMTP is fine, and reaching for an API is over-engineering.

What’s next

• Send email without SMTP for the full send flow through the REST API
• Send transactional email from a domain for app-generated mail with no user grant
• IMAP vs an email API to compare the reading side in depth
• Getting started with Nylas to create a project, connector, and your first grant