Email API vs SMTP: Which to Use

Command references used in this guide: nylas email send, nylas email list, and nylas init.

What is the difference between an email API and SMTP?

SMTP (Simple Mail Transfer Protocol) is the standard for sending mail between servers, defined originally in 1982 and updated in RFC 5321. Your code opens a socket to a mail server, authenticates, and hands over a message — that's the entire job. SMTP has no concept of reading an inbox, searching, or being notified when mail arrives; it is one-directional by design.

An email API is an HTTP interface that wraps far more than sending. Through REST calls it sends, reads, searches, lists folders, manages drafts, and delivers webhooks when something changes — returning JSON your code parses directly. SMTP moves a message; an API operates on the mailbox. That scope difference, not performance, is what the decision turns on.

What can SMTP do, and not do?

SMTP can send a message reliably from almost any language, since every stack has an SMTP client and every provider runs a submission server on port 587 or 465. For “email me when this cron job finishes,” that's exactly enough. What it can't do is everything after the send: it never reads the reply, can't tell you if the message was opened, and offers no search.

It also carries operational friction. Authentication for personal accounts now requires app passwords — Google removed plain-password SMTP in September 2024, per its Gmail SMTP documentation — and cloud providers commonly block outbound SMTP ports to fight spam, so a script that works locally can fail on a VM. SMTP is simple until those edges, then it isn't.

What does an email API add?

An email API adds the entire read side and the tooling around delivery. It lists and searches the inbox, reads message bodies and attachments, manages drafts and threads, and pushes webhooks on new mail or bounces. Authentication is OAuth — scoped, revocable, and refreshing automatically — rather than a reusable app password, and it talks over HTTPS port 443, which cloud firewalls don't block.

When is plain SMTP enough?

SMTP is the right tool when the whole task is “send one message” and you don't care about anything after. A backup script emailing a completion notice, a monitoring alert, a form that fires a single confirmation — all are clean SMTP jobs, and reaching for an API would be overkill. If you never read the reply and never need to know what happened to the message, SMTP's simplicity wins.

It stops being enough the moment a second requirement appears: you want to process replies, track opens, search past mail, or trigger on incoming messages. At that point you're rebuilding pieces of an API on top of SMTP and IMAP by hand, which is more work than adopting the API was. The line is sharp — one-way send versus working with the inbox.

Where does the CLI sit?

The CLI is the API path without the integration work. nylas email send sends over the API — no SMTP host, port, or app password — and the same connection also runs nylas email list, email search, and webhooks. You get the API's full scope from the terminal after one nylas init, and because it's HTTPS on 443, it runs identically on a laptop and a cloud runner where SMTP ports are blocked.

So the decision in practice: if you genuinely only ever send, plain SMTP from your language's standard library is fine. If there's any chance you'll need to read, search, or react, start on the API side and skip the eventual migration. See send email with curl for the raw-SMTP route and IMAP vs Gmail API vs Graph API for the read-side protocols.

# The API path — send and read from one connection, no SMTP config
nylas init
nylas email send --to user@example.com --subject "Done" --body "Job finished."
nylas email list --json --limit 5   # SMTP can't do this line

Next steps

• Send email with curl — the raw SMTP route and its gotchas
• IMAP vs Gmail API vs Graph API — the read-side protocol comparison
• Gmail SMTP settings — ports, TLS, and app passwords if you stay on SMTP
• Send email from the terminal — the API path end to end
• Full command reference — every flag and subcommand documented