Updated · 7 min read
SMTP vs API sending: which integration pattern your program needs
You're integrating a new system with your ESP and have to choose — SMTP relay or HTTP API. Both work; they have different trade-offs in reliability, latency, feature access, and implementation effort. Most programs end up with both, each used for what it's best at. Here's the decision framework.
Justin Williames
Founder, Orbit · 10+ years in lifecycle marketing
The two patterns
SMTP (Simple Mail Transfer Protocol). Your system connects to your ESP's SMTP server, hands off the composed email, and the ESP handles the rest. Works with every email library, every language, every framework. The same protocol mail has used since 1982.
API (HTTP/REST). Your system makes HTTPS calls to the ESP's API, passing recipient, template ID, merge variables, and metadata in JSON. The ESP composes and sends. Modern, structured, faster, feature-rich.
SMTP is universal and battle-tested. API is fast, structured, and modern. Neither is "better" — they solve overlapping but different problems, and most programs use both.
The comparison
| Dimension | SMTP | API |
|---|---|---|
| Integration effort | Low (every lang has a library) | Medium (ESP-specific SDK or HTTP) |
| Latency | ~500ms–2s per message | ~50–200ms per call |
| Throughput | Connection-bound; harder at high volume | Scales horizontally |
| Feature access | Basic sending only | Templates, merge vars, tracking opts, batching |
| Deliverability feedback | Bounces via return-path; delayed | Webhooks; near real-time |
| Dependency on ESP | Loose (standard protocol) | Tight (ESP-specific payload format) |
| Template management | Client-side (compose the email) | ESP-side (reference by ID) |
| Typical use case | Legacy apps, low-volume, fallback | Modern lifecycle, high-volume, rich data |
When SMTP is the right call
Legacy systems. CRMs, ticketing systems, old CMS products that already know how to send SMTP. Swapping them to API is engineering work; pointing them at your ESP's SMTP endpoint is configuration.
Low volume, low complexity. A simple notification system sending 1,000 mails/month doesn't need template management or rich tracking. SMTP is overhead-free.
Fallback path. Many programs use API as primary, SMTP as fallback for when the API is unavailable. Redundancy pattern.
Vendor independence. SMTP is standard; migrating between ESPs that support SMTP relay is a DNS change. API-native integrations require re-coding for each vendor.
When API is the right call
High-volume programs. At 100K+ sends/day, API's throughput and batching advantages show up clearly. SMTP connection limits become a bottleneck.
Templated sends with merge fields. API lets you reference template IDs and pass merge variables, so the content is managed in the ESP and the integration sends only the data. SMTP requires full-email composition in your code.
Real-time event tracking. API integrations get webhook feedback on delivery, opens, clicks, bounces, complaints. Near real-time. SMTP provides delivery status via bounces on return-path; tracking requires additional machinery.
Rich lifecycle logic. API integrations can pass metadata (user ID, campaign ID, segment) that gets stored alongside the send record, making analytics and troubleshooting easier.
The hybrid pattern
Most programs at scale end up with both:
API for marketing/lifecycle: broadcast campaigns, triggered flows, transactional with rich logic. The main channel, optimised for throughput and observability.
SMTP for adjacent systems: legacy CRMs, support ticketing, password resets from auth systems. Systems that are not worth re-integrating.
,
Practical integration considerations
Retry handling. API errors need app-level retry logic with exponential backoff. SMTP has retry built into the protocol. If your code isn't handling API errors, you're silently dropping mail on transient failures.
Rate limiting. APIs enforce rate limits (requests per second); SMTP uses connection limits. Batch your API calls to stay under limits; pool SMTP connections.
Authentication. SMTP auth is per-connection credentials; API is per-request API key (usually) or OAuth. Rotate keys regularly.
Monitoring. API integrations should send to a test address and verify the webhook fires. SMTP integrations should include a smoke test that sends from the actual production code path. Silent send failures are one of the top lifecycle incidents.
The Deliverability Management skill covers the decision framework when a team is choosing integration patterns for a new system, and the specific redundancy patterns used at scale.
Frequently asked questions
- Should I start with SMTP or API?
- For a new lifecycle system with a modern ESP, API. The richer feature set (templates, webhooks, metadata) pays off quickly. For legacy systems already using SMTP, don't migrate unless there's a clear benefit. SMTP works fine for basic sending; don't create migration work for its own sake.
- Is API faster than SMTP?
- Yes, usually. API calls complete in ~100ms vs SMTP's 1–2 seconds (mostly due to SMTP's connection setup and handshake). At low volume, the difference doesn't matter. At high volume, API's speed becomes a real throughput advantage.
- What's the performance difference at scale?
- At 10K sends/hour: both handle it easily. At 100K/hour: SMTP needs connection pooling; API scales naturally. At 1M/hour: API is dominant; SMTP requires significant infrastructure work (multiple concurrent connections, load balancing).
- Can I use both API and SMTP with the same ESP?
- Yes — most ESPs support both, and many programs use both for different use cases. Keep them on separate subdomains if the mail types are different (e.g., marketing API + transactional SMTP).
- Which gives better deliverability?
- Neither inherently. Deliverability is a function of reputation, authentication, and content. Both SMTP and API senders can have excellent or terrible deliverability depending on how they're used. The integration pattern doesn't affect the outcome.
- What about AWS SES, Postmark, SendGrid — are these different?
- All three offer both SMTP and API. They differ on pricing model, feature emphasis, and target use case (SES: raw infrastructure, low cost; Postmark: transactional focus, high reliability; SendGrid: broader marketing focus). The SMTP vs API choice is orthogonal to ESP choice.
This guide is backed by an Orbit skill
Related guides
Browse all →Email deliverability — the practitioner's guide
Deliverability is the cumulative result of every send decision over the lifetime of a domain. This guide covers the four pillars — authentication, reputation, engagement, and list hygiene — and how to recover when one breaks.
The unsubscribe page is the most important page in your lifecycle program
The page every lifecycle team ignores is the one that quietly decides sender reputation, suppressed-list quality, and the fate of your next quarter's deliverability. A short defence of why it's worth the ten-minute rebuild.
SPF, DKIM, and DMARC explained for lifecycle marketers
Three DNS records decide whether your marketing email is trusted or binned. Gmail and Yahoo have required all three for bulk senders since 2024. This is the practitioner's explainer — what each one does, how they interact, and the configuration that actually works.
Dedicated vs shared IP: the real decision
Every Braze sales conversation pitches the dedicated IP. Most programs don't need one. Here's the volume threshold that actually justifies a dedicated IP, the risks most teams don't anticipate, and when the shared pool is genuinely the better call.
List hygiene: the six-rule policy
List hygiene isn't cleanup; it's a continuous policy that runs automatically. Here's the six-rule policy every lifecycle program should have written down, each tied to a specific deliverability outcome.
Bounce rate management: the thresholds and the fix order
Bounce rate is the simplest deliverability metric to read and the easiest to get wrong. Here's what each bounce type actually means, the thresholds that trigger real problems, and the fix order when your bounce rate starts climbing.
Found this useful? Share it with your team.