smtp vs. API for email service providers

not sure you clearly differentiate.
SMTP suggest that you would write your own handler to transact SMTP sessions when sending is needed versus using built-in tools into whatever programming language to handle the same interchange.
Often, depending on the platform/os availability of a local mail server non-SMTP (direct or via api) is often better.

SMTP is only universally supported mail transfer protocol.

ok so im hearing smtp  = api in terms of deliverability?

thanks!

with smtp you can run local mail server than handles retries for deliverability. with proprietary API you must organize queue yourself.

The final interaction is SMTP. The API provides additional functions and a simplified interaction between the programmer and the .....


Your application => mail server via SMTP
Your application <=> API with some additional options/functions<=> mail server via SMTP

If your deploying your application in an environment with a builtin mail server running on the same system, there are way to send a message without going through SMTP session/transaction.
Deals with placing the properly format message in a pickup folder or passing the properly formatted message to the application that saves it into the queue.

The problem with that arrow between API and Application might be 10000 miles of wires (heard of cloud and back)
So it is super unreliable in the end.

i am using mailguns smtp . so my local is not being used right? that would be a cloud smtp?

another way of saying
API is more for developer
SMTP more for administrator (configuration based)

I am not sure I would put it that way, the selection actually depends on what the purpose it should serve.

To send out email, one has to use an email server local is better than remote minimizes overhead for sending out emails, error handling on the SMTP exchange, etc.

let me backtrack a bit given the interpretation I have for the reason of your question deals with solely to send out emails.

If you have a more detailed explanation of what your goals are, what interaction does your application must have?
What features your application needs to support, etc.

It could be the api as you've chosen is the optimal choice for your need.
I.e. You need your application to gave access/interaction with replies toenails you send.
Auto handling subscription management, etc.

I do not see any added value in
1) paying .02c per mail where it is free to send otherwise.
2) using single-vendor HTTP API over unstable internet vs having SMTP on the host where mail is generated.

Not disagreeing with you Gheist,

There must be a reason/criteria that might make that features/options at mailgun.com's API the user needs that are not related to the sending of email.

Presumably the receive/track features.
One can always configure their own SMTP and then setup log cruncher to get the data out to help track outgoing, then deal with the incoming emails.

.....

If everything is in house you can trace all mails perfectly.