Email API vs SMTP: Which One Should You Use?
SMTP and HTTP APIs both send email but suit different situations. SMTP is right for existing libraries and tools that only speak SMTP. The HTTP API is right for new code, cloud functions, idempotency, webhook tracking, and attachments. A comparison table and guidance on using both.
When your application needs to send email, you have two ways to hand the message off: SMTP or an HTTP API. They both deliver email, but they work differently and suit different situations. Here is how to choose.
How each one works
SMTP is the protocol email has always used. Your application opens a TCP connection to a mail server, authenticates, and issues a sequence of commands — EHLO, MAIL FROM, RCPT TO, DATA — to transfer the message. The server queues it and handles delivery from there.
An HTTP API wraps the same operation in a REST call. You send a POST request with a JSON body containing the recipient, subject, and body. The API server does the SMTP leg on your behalf and returns a message ID.
Comparison
| SMTP | HTTP API | |
|---|---|---|
| Port | 465 (SSL) or 587 (STARTTLS) | 443 (HTTPS) |
| Cloud blocking | Port 25 is blocked; 465/587 usually open | 443 is never blocked |
| Auth | Username + password or SASL | Bearer token in header |
| Retry on failure | Client handles it | Provider handles it |
| Idempotency | Not built in | Idempotency-Key header |
| Batching | One connection per session | Array of recipients in one call |
| Attachments | MIME encoding in the DATA payload | Base64 in JSON body |
| Monitoring | Log parsing | Webhook events per message |
When to use SMTP
Existing software that speaks SMTP. If you are using a mail library like Nodemailer, PHPMailer, or ActionMailer, they all support SMTP out of the box. Configuring the host and port is faster than switching to a new library.
Tools that only support SMTP. Some monitoring systems, ERPs, or legacy applications let you configure an SMTP relay but have no HTTP client. SMTP is the only option there.
Local development with a sink. Tools like Mailpit or Mailhog expose a local SMTP server that captures mail instead of sending it. Pointing your dev config at localhost:1025 is the fastest way to test email rendering without sending real messages.
When to use the HTTP API
New code you are writing. fetch is already in your runtime. You get a structured response, a message ID, and webhook events without any extra library.
Cloud functions and serverless. Many cloud providers block outbound SMTP from function runtimes. Port 443 is always open.
Idempotency. The Rovela API accepts an Idempotency-Key header. If a network timeout forces a retry, the same key within 24 hours returns the original result without sending a duplicate message. SMTP has no equivalent mechanism.
Webhooks and status tracking. Every message sent via the API can emit webhook events — delivered, bounced, complained. SMTP gives you no feedback after the handoff.
Attachments without MIME. Attaching a file over the API is a base64 string in a JSON field. Getting MIME right in a raw SMTP DATA payload is fiddly.
Using both
A common pattern: the application uses the HTTP API for transactional mail (receipts, notifications, password resets) where idempotency and webhook tracking matter, and an SMTP relay for a legacy subsystem that already works and has no reason to change.
Rovela supports both. The SMTP relay accepts credentials from any mailbox or API key with sending scope. The HTTP API is at https://api.rovela.dev/emails.
Further reading: Sending email from Next.js, Idempotency keys: preventing duplicate sends on retry, SMTP ports 25, 465, and 587.