Learn

SMTP or an email API: two doors into the same room.

SMTP is the protocol mail has always used. An email API is an HTTPS call that describes a message. With Notix both end in the same log, the same suppression list and the same webhooks, so the choice is about what your code can express, not what you get afterwards.

Criterion by criterion

The differences that matter for someone deciding, and the ones that turn out not to matter at all.

SMTP relay compared with the email API
Criterion	SMTP relay	Email API
Transport	SMTP over TLS on 465 or STARTTLS on 587, a multi-step conversation.	One HTTPS POST with a JSON body.
Authentication	Username notix, your API key as the password.	Authorization: Bearer with the same API key.
Latency	Several round trips per message; a client library keeps a connection open.	One request; a batch endpoint sends 100 in one call.
Retries	The client retries the conversation; a duplicate is possible if the first attempt succeeded after a timeout.	An Idempotency-Key header makes a retry return the original id instead of sending twice.
Attachments	MIME parts, decoded by the relay and passed through under the same limits.	Base64 in the request: 10 files, 7 MB each, 10 MB per email decoded.
Templates and variables	Not possible; you render the HTML yourself.	templateId plus variables; the template is versioned in the dashboard.
Scheduling and batch	Not possible.	scheduledAt per message; batches of 100; PATCH to move, cancel until sent.
Tracking, suppression, webhooks	Identical: the relay writes to the same log.	Identical.
Best for	Software you did not write: Supabase Auth, WordPress, Rails ActionMailer, a printer.	Code you write: receipts, codes, notifications, campaigns.

The last three rows are the decision. Templates, scheduling, batches and idempotency exist only on the API, because SMTP has no field to carry them. Tracking, suppression and webhooks are the same on both, because the relay is a client of the API.

The same receipt, both ways

Over SMTP you render the HTML and hand over a finished message. Over the API you name a template, pass the variables, and add a key so a retry cannot send twice.

Same message through the relay

import nodemailer from "nodemailer";

const transporter = nodemailer.createTransport({
  host: "smtp.usenotix.dev",
  port: 465,
  secure: true,
  auth: { user: "notix", pass: process.env.NOTIX_API_KEY },
});

await transporter.sendMail({
  from: "receipts@mail.acmepay.com",
  to: "chidi@example.com",
  subject: "Your receipt #48213",
  html: renderReceipt(order), // you render it; no templateId over SMTP
});

Same message through the API

import { Notix } from "notix-js";

const notix = new Notix(process.env.NOTIX_API_KEY);

const { data, error } = await notix.emails.send(
  {
    from: "receipts@mail.acmepay.com",
    to: "chidi@example.com",
    templateId: "tpl_receipt_v4",
    variables: { orderId: "48213", total: "₦12,400" },
  },
  { idempotencyKey: "order-48213-receipt" }, // a retry never sends twice
);

No SDK needed

curl -X POST https://app.usenotix.dev/api/v1/emails \
  -H "Authorization: Bearer $NOTIX_API_KEY" \
  -H "Idempotency-Key: order-48213-receipt" \
  -H "Content-Type: application/json" \
  -d '{ "from": "receipts@mail.acmepay.com", "to": "chidi@example.com",
        "templateId": "tpl_receipt_v4", "variables": { "orderId": "48213" } }'

What the relay actually does

The relay at smtp.usenotix.dev accepts the message over TLS on 465 or STARTTLS on 587, authenticates with the username notix and your API key as the password, parses the MIME message, and makes the same POST to /api/v1/emails that the SDK makes: from, to, subject, text, HTML, reply-to, the headers it forwards, and the attachments decoded from their MIME parts. From there the message is a Notix message like any other. What the relay cannot do is invent fields the protocol never carried: there is no template id, no variables, no schedule and no idempotency key on an SMTP send.

When to choose which

Choose the SMTP relay when

The sender is software you did not write and would rather not change.
You are moving off another SMTP provider and want the swap to be a host and a password.
A platform only offers custom SMTP for its own mail, as Supabase Auth and Firebase Auth do.

Details on the SMTP relay page.

Choose the API when

You write the code that sends, in any language with an HTTP client.
A duplicate would cost you: receipts, one-time codes, payouts.
You want templates versioned in the dashboard, batches, or sends scheduled for later.

Details on the email API page and in the docs.

What is the difference between SMTP and an email API?

SMTP is the mail protocol itself: your software opens a connection to a mail server and hands the message over in a multi-step conversation, the same way mail has moved since the 1980s. An email API is an HTTPS endpoint: one POST with a JSON body describing the message. Both end with the same delivery. The API adds things the protocol has no field for: templates with variables, an idempotency key, scheduling and batches. SMTP wins when the sending software already exists and you cannot or would rather not change it.

Is an email API faster than SMTP?

Per message, an HTTPS POST is one request where an SMTP send is several round trips, so the API is quicker from a cold start. A client library that keeps an SMTP connection open closes most of the gap for steady traffic. Where the API is decisively faster is volume: a batch call sends 100 messages in one request, and scheduling lets you hand over a send now and have it go later.

Do I lose tracking, suppression or webhooks by using SMTP?

No. The Notix relay turns each SMTP message into the same API call your code would make, so it lands in the same log with the same domain settings. Open and click tracking follow the sending domain's switches, suppressed addresses are dropped, bounces and complaints suppress the address, and every delivery event reaches your webhook endpoint whichever door the message came in through.

Can I use templates over SMTP?

Not Notix templates. SMTP carries a finished message: subject, text, HTML, attachments, headers. There is no field for a template id or variables, so over SMTP you render the HTML yourself before sending. If you want templates versioned in the dashboard and filled from variables, that is the API.

What about idempotency over SMTP?

There is none at the protocol level. If your SMTP client times out after the server actually accepted the message and then retries, the message goes twice. The API's Idempotency-Key header solves this: a retry with the same key within 24 hours returns the original email id and sends nothing. For receipts and codes, where a duplicate costs trust, that alone is a reason to use the API from code you control.

Which should a new project use?

The API, from code you write. Use the SMTP relay for the parts of the stack that already speak SMTP and would need a rewrite otherwise: Supabase Auth's custom SMTP, WordPress through an SMTP plugin, Rails ActionMailer, a firewall or a printer that emails reports. Many teams run both, against the same domain, and see one log.

Product

Send your first email in five minutes.

Verify a domain, copy an API key, make one call. The free plan does not ask for a card.

Start free, no card Read the docs

SMTP or an email API: two doors into the same room.

Criterion by criterion

The same receipt, both ways

What the relay actually does

When to choose which

Choose the SMTP relay when

Choose the API when

SMTP relay

Email API

Send email from Node.js

SPF records for transactional email

WordPress

Pricing

Send your first email in five minutes.

SMTP or an email API: two doors into the same room.

Criterion by criterion

The same receipt, both ways

What the relay actually does

When to choose which

Choose the SMTP relay when

Choose the API when

Keep reading.

SMTP relay

Email API

Send email from Node.js

SPF records for transactional email

WordPress

Pricing

Send your first email in five minutes.