SMTP vs email API

SMTP (Simple Mail Transfer Protocol) is the protocol servers use to relay mail. An email API is a provider's HTTPS interface for the same job. Either way your message ends up at the provider, which delivers it onward over SMTP.

What each looks like

SMTP from an application:

1. Open a TCP connection to the provider on port 587 (STARTTLS) or 465 (implicit TLS).
2. Authenticate with credentials.
3. Issue MAIL FROM, RCPT TO, DATA.
4. Receive a reply code.

API:

POST /transactional/send   (JSON, Bearer token)  ->  200 {"status": "sent", "message_id": "..."}

Comparison

| | SMTP | Email API | |---|---|---| | Setup | Host, port, username, password | API key | | Works with software that only has SMTP settings | Yes | No | | Error detail | Reply codes and text | HTTP status plus JSON error code | | Templates and merge data | Render before sending | Often built in | | Scoped credentials | Usually one credential per account or identity | Keys with scopes, expiry and IP rules | | Attachments, CC, BCC | Native | Depends on the provider | | Network | Needs outbound SMTP ports open | HTTPS 443 only | | Connection handling | Pooling, reconnects | Your HTTP client |

One practical point: many cloud hosts block outbound port 25 and some restrict 465 and 587. HTTPS on 443 is almost never blocked.

How to choose

Use SMTP when:

• You configure existing software (a CMS, a helpdesk, a printer) that offers only SMTP settings.
• You rely on attachments, CC or BCC and your provider's API lacks them.

Use an API when:

• You write the sending code yourself.
• You want structured errors, scoped keys and template rendering in one call.
• Your host restricts outbound SMTP.

What Inboxili supports

Inboxili is API-only today. There is no SMTP endpoint, and the API has no attachment, CC or BCC fields. If you need those or can only configure SMTP, Inboxili is not the right fit yet. If you write your own backend, the API covers templates, merge data, scoped keys and signed webhooks. See the API reference by example.