SMTP or REST API: which to integrate against

Both deliver the same mail through the same infrastructure. The difference is what your application knows afterwards.

What SMTP gives you

Compatibility, immediately. Every language has a mail library, every framework has a mail configuration, and every CMS has an SMTP settings page. Changing host, port and credentials is often the whole integration.

If you are migrating from another provider, or from a server in a cupboard, SMTP means the application code does not change at all.

It is also the only option when you do not control the code — a CMS plugin, an appliance, a vendor application with a settings screen and nothing else.

What SMTP costs you

Errors are codes and prose. A rejection is a three-digit code and a line of text that varies by implementation. Parsing it to decide what your application should do is unpleasant and fragile.

No message ID you can use. You can generate your own Message-ID header, but correlating it with platform events is work you have to build.

Connection management. Opening a connection per message is slow and wasteful; pooling them correctly is work.

No batching. One message per transaction.

What the API gives you

An ID per message, immediately. Store it against your order or your user and every later event — delivered, bounced, complained — joins to it.

Structured errors. A machine-readable reason, not prose to parse.

Batching. One request, many messages, per-message results.

Features that have no SMTP equivalent — template references, scheduling, tags, per-message metadata that comes back on the webhook.

What the API costs you

Writing an integration. It is a day rather than an hour, and it is code you own and maintain.

Choosing

Use SMTP when you are migrating existing code, integrating software you do not control, or sending low volume where the extra visibility is not worth the work.

Use the API when you need per-message tracking, when you send in batches, or when the application should react to delivery events rather than just hoping.

The honest default: start with SMTP because it works today, and move to the API when you find yourself wanting to answer a question SMTP cannot. For most teams that question is "what happened to this specific message", and it arrives sooner than expected.

Both at once is fine

There is no reason to pick one globally. A legacy subsystem on SMTP and a new service on the API send through the same pipeline, sign with the same keys and share the same reputation. See which SMTP port to use if you go that route.