Why Sendonis is API-only, and why we don't offer SMTP

Sendonis is launching soon. This post explains a design decision behind it. Join early access to hear when it's live.

One of the first questions people ask about Sendonis is: "Where are the SMTP credentials?" There aren't any. Sendonis will accept email only through its REST API. We won't run an SMTP relay for customers, and we don't plan to make SMTP a way to send through us.

This post explains why. In short, an API gives us, and you, more control at the moment that matters most: before a message is accepted for delivery.

A quick refresher: two ways to hand off email

When an application sends email through a provider, it usually does one of two things:

• SMTP submission. The application opens a connection to the provider's mail server, logs in with a username and password, and speaks the SMTP protocol: who the message is from, who it's for, then the raw message itself.
• HTTP API. The application sends an authenticated HTTPS request with a structured body, usually JSON, describing the message. The provider answers with a status code and an identifier.

Both work. SMTP is the older, universal standard, and plenty of software can speak it without any changes, which is its biggest advantage. But for a service like Sendonis, whose whole point is to protect senders and the shared platform, the API model fits much better.

1. Validation happens before acceptance

With an API, every request is a single, complete, structured object. We can check it in full before we say yes:

• Is the from address on a domain this account has verified?
• Are any recipients on this account's suppression list?
• Is the account currently allowed to send, or has sending been paused because of high bounce or complaint rates?
• Is the request inside the account's rate and volume limits?

If something is wrong, the API returns a clear error with a reason, and nothing has been sent. Your code can handle that error like any other failed HTTP call.

SMTP can reject messages too, but its error model is coarser and harder to act on. Many client libraries and applications treat a successful SMTP handoff as "sent" and log little detail about rejections. An API response is much easier to read in code and to monitor.

2. Credentials that are easier to scope and rotate

SMTP authentication is usually a username and password stored in an application's mail configuration. These credentials tend to end up copied into many places: config files, CMS plugins, CI variables, old servers nobody remembers. When one leaks, it often isn't noticed until it has been used to send spam.

Sendonis will use API keys sent as bearer tokens over HTTPS. Keys belong to one account, can be created per application or environment, and can be revoked and rotated without touching anything else. Because each key is tied to one tenant, every request is clearly attributed. We always know which account sent a message, which matters for both support and abuse handling.

3. Safe retries with idempotency

Networks fail. A request can time out after the provider has already accepted the message. If the client simply retries, the recipient may get the same email twice. For a password reset that's annoying; for a payment receipt it's confusing.

An HTTP API can support an idempotency key: the client sends a unique key with each logical message, and if the same key arrives again the service returns the original result instead of sending a duplicate. SMTP has no standard way to do this. An HTTP API makes this pattern possible; SMTP doesn't.

4. Structured data in, structured events out

An API lets you attach metadata to a message: tags, your own identifiers, the type of email. That metadata comes back with every delivery, bounce and complaint event on your webhook. You can tie each event to the order, user or workflow that triggered it without parsing headers.

Under the hood, Sendonis will attach a tenant identifier to every message it sends. Each event that comes back is matched to the right account and its suppression list before it reaches you. The API is the point where all of that is set up.

5. Abuse control on a shared platform

Sendonis is multi-tenant. Many customers share sending infrastructure, so one customer's bad behaviour can affect others if it's left unchecked. That's why our Acceptable Use Policy is strict, and why we'll pause accounts automatically when bounce or complaint rates cross safe limits.

An open SMTP endpoint is an attractive target. Leaked SMTP credentials are a common route for spam, and SMTP traffic is often generated by software the account owner doesn't fully control, such as plugins, legacy apps and forwarding rules. Accepting mail only through an authenticated API, with per-tenant keys and checks on every request, narrows that attack surface considerably.

"But my app only speaks SMTP"

That's a fair concern, and for some teams it settles the question. If you run software that can only send through SMTP and can't be extended, Sendonis may not be the right fit, and we'd rather tell you that now.

In practice, though, most modern stacks have an easy route to an HTTP API:

• Most web frameworks let you replace the mail transport with a custom HTTP-based one.
• Any language with an HTTP client can call the API directly. The request is a few lines of code.
• Background job systems are a natural place to call an API and record the returned message ID.

Our documentation will include a complete example at launch.

A note on the word "SMTP" in your DNS

When you set up a custom MAIL FROM domain with Sendonis, one of the DNS records is an MX record pointing to a bounce-feedback host, and these hostnames often contain the word "smtp". That doesn't contradict anything above. The record tells receiving mail servers where to send bounce notifications for your messages, so they can be passed back to Sendonis. It's part of how feedback works, not a way for you to send. Our DNS guide explains each record.

The trade-off, stated plainly

API-only means a little integration work up front, instead of pasting SMTP settings into a config screen. In return you get:

• clear, immediate errors when a message can't be sent;
• per-application keys you can revoke without disrupting everything else;
• safe retries;
• your own metadata on every event;
• a platform that is harder to abuse, which protects your reputation as well as ours.

We think that's a good trade for any application that depends on email arriving. If you'd like to be among the first to try it, join early access.