What's the difference in one line?
SMTP is the open protocol your software uses to hand mail to a server; an email API is a provider-specific HTTPS interface that does the same job with structured payloads and event feedback. The submission protocol does not decide whether you reach the inbox — authentication and domain reputation do, and SPF, DKIM, and DMARC apply identically to both paths. So choose on integration grounds: portability, error handling, tooling. For everything that happens after your provider accepts the message, email deliverability for startups is the guide.
How does sending over SMTP work?
Your application opens a connection to your provider's server, the SMTP relay — for submission, typically port 587 with authentication, as specified by RFC 6409 — and hands over the finished message. The transfer protocol itself is RFC 5321, standardized in its current form in 2008 and in use far longer, which is why everything speaks it: any framework, CMS, forum, monitoring tool, or decades-old script can send this way with nothing but a host, a port, and credentials. That is SMTP's quiet advantage — migration is a credential swap, so switching email platforms never means rewriting the sending code. It is also the natural fit for self-hosted stacks, where SMTP support ships by default.
How does sending over an email API work?
Your code calls the provider's HTTPS endpoint with a JSON payload — recipient, content or a template reference, tags, metadata, often an idempotency key to guard against duplicate sends. The response is synchronous: success with a message ID, or an error your code can catch and retry. Postmark's docs make the contrast explicit — its REST API returns success or an error immediately, while its SMTP endpoint accepts all messages and logs any errors as bounces, still retrievable through its bounce webhooks. After acceptance, webhooks push bounces, complaints, and opens back to your app, which is what makes automated suppression possible. Provider SDKs wrap all of this in a few lines; in exchange, the integration is specific to that provider.
SMTP vs API: the head-to-head
The whole decision compresses into one trade: SMTP buys portability, the API buys feedback and tooling. Here is how that plays out line by line.
| SMTP | Email API | |
|---|---|---|
| What it is | Open protocol (RFC 5321) — the same everywhere | Provider-specific product interface over HTTPS |
| Integration effort | Near zero if the software already speaks SMTP: host, port, credentials | Code against the provider's endpoint or SDK |
| Portability | High — switching providers is a credential swap | Low — every provider's format differs; switching means rewriting the integration |
| Failure semantics | Accepted at submission; some failures surface later as asynchronous bounces | Synchronous errors you can catch and retry, plus asynchronous events |
| Event feedback | Nothing in the protocol — provider bounce webhooks still cover SMTP-submitted mail, but you wire them separately | Webhooks push bounces, complaints, and opens to your app |
| Templates and analytics | Nothing in the protocol — you send a finished message | Template references, tags, and per-message metadata |
| Self-host fit | Natural — self-hosted software speaks SMTP out of the box | One more vendor-specific dependency in your stack |
When is SMTP the right choice?
- Software that already speaks it — a CMS, forum, helpdesk, or legacy app starts sending through your provider with nothing but new credentials.
- Maximum portability — if you want the freedom to change providers without touching code, SMTP is the neutral interface.
- Self-hosted stacks — SMTP support is built into virtually everything you would run on your own infra, no SDK required.
- Low-volume operational mail — cron alerts and internal notifications rarely justify a bespoke API integration.
When is the API the right choice?
Product sending at scale. When email is wired into your application — onboarding, receipts, lifecycle flows — synchronous errors, template references, and event webhooks earn their integration cost, and a suppression list can update itself the moment an address bounces or complains. One thing the API does not buy you is reputation: that lives on your sending domain, not on your submission path, so domain warmup and authentication apply identically whichever way you submit.
Why does fromHello support both?
Because the choice is an integration decision, not a deliverability one, the platform ships both provider adapters: fromHello sends email through Resend or through any SMTP server, and you pick per workspace. Point it at the provider you already trust. Limits sit at the provider level either way — Resend, for one, documents the same rate limit for its SMTP endpoint as for its API. And suppression and consent are enforced by the platform regardless of the submission path: a suppressed address stays suppressed whether the message leaves over HTTPS or port 587.