SMTP or the API
A real decision, not a preference. What each one gives you.
Both send mail. They are not interchangeable, and the right answer depends on something specific: whether you are writing the integration or inheriting one.
The short version
Use SMTP when something already speaks it — WordPress, a Rails app with ActionMailer, a printer, a monitoring tool, anything whose mail configuration is four fields and no code.
Use the API when you are writing the integration yourself. It gives you things SMTP submission structurally cannot.
What the API gives you that SMTP does not
| API | SMTP | |
|---|---|---|
| Message id at submission | Yes, in the response | No — assigned later |
| Per-message tags | Yes | No |
| Correlating events to a send | Direct, by message_id |
By recipient and timestamp, approximately |
| Batch with per-recipient variables | One call, 500 recipients | One connection per message |
| Stored templates | template_id |
Render it yourself |
| Failure detail | Immediate, structured | A status code and a text string |
The one that matters most in practice is the first. With the API you get a message_id in the
response and can store it against your order, ticket or user. When a delivery event arrives later,
you know exactly what it refers to. Over SMTP you are matching on recipient and time, which is
approximate, and stops being good enough the moment you send the same person two things in a minute.
What SMTP gives you
It already works. Every language, every framework, every appliance. If your application sends mail today through some other provider's SMTP, switching to Mailyte is four configuration values and no deploy of application code.
That is not a small thing. The best integration is often the one you do not have to write.
Setting up SMTP
curl -X POST "$MAILYTE_BASE/api/v1/smtp-credentials" \
-H "Authorization: Bearer $MAILYTE_API_KEY" \
-H 'Content-Type: application/json' \
-d '{"domain_id": "01JBT8XQ2M9WYC3K4F6R7S8T9V", "name": "website-contact-form"}'The response carries the host, port, username and password — the four things every mail library asks for. The password is shown once and is stored only as a hash. If it is lost, rotate.
Credentials are scoped to one domain. One per system, so revoking one never takes down three things you had forgotten shared it.
Not the same as a mailbox password
Three different credentials exist here and they are revoked and rotated separately:
- A mailbox password is for a person reading their mail.
- An SMTP credential is for an application relaying mail.
- An API key is for an application calling this API.
Using a mailbox password as an application's SMTP login works, and it is a bad idea: the person changes their password, your invoicing system stops sending, and nothing connects the two events.
You can use both
Most people do. SMTP for the legacy application nobody wants to touch, the API for the new work. They share domains, senders, suppressions and delivery events, so the event log tells one story regardless of how the message was submitted.
Rate limits apply to both
Sending limits are enforced at the mail server, not at the API, so relaying over SMTP does not sidestep them — and it should not. This was once genuinely possible: a submission port stripped the policy and roughly 60% of outbound was effectively unlimited. It is enforced on every path now, and the limits count recipients rather than messages.
Next
Handling delivery events — the same for both paths.