In this guide 6 sections
Use SMTP relay when an existing application already sends mail and you want delivery working this week. Use the API when you need a message ID saved against the order, templates that staff edit, and clear handling of temporary and permanent failures. Most new builds are better served by the API.
What each route actually hands to Brevo
SMTP relay behaves like any mail server. Your application opens a connection, authenticates with an SMTP key, and pushes a fully built message with headers, HTML body and attachments. Brevo accepts it and returns a plain acceptance reply.
This route is different. Your application posts a small JSON request naming a template, a recipient and a set of parameters. Brevo builds the message itself and answers with a message ID you can store.
That one difference drives everything below. SMTP gives you a handover. The API gives you a handover plus a handle.
- SMTP: host, port, login and a key, nothing else to learn
- API: an HTTPS call with an API key and a JSON body
- SMTP: your code owns the whole MIME message
- API: Brevo owns the template and the layout
Queueing and what happens during a spike
Both routes need a queue on your side. If your application sends mail inside the web request, a slow reply from Brevo makes the customer wait on the checkout page. Put each send into a job table or a queue and let a worker process it.
SMTP workers tend to hold one connection open and send many messages down it, which is gentle on limits. API workers make one HTTPS call per message, so you must respect the rate limit and back off when told to.
Either way, write the job row before you call Brevo. A crash between the call and the save then leaves a row marked pending, not a lost email.
Keeping delivery status against the order
Here the API wins clearly. The message ID it returns can sit in a column beside the invoice or order. A webhook from Brevo later reports delivered, soft bounce, hard bounce, blocked or spam complaint, and you match it back by that ID.
With SMTP you get no useful ID at the moment of sending. You can still receive webhook events, but matching them to an order means stamping a custom header or tag on every message and hoping nothing strips it.
Support staff feel this difference. When a customer says the invoice never came, one screen showing sent, delivered and opened beats a hunt through logs.
- Message ID stored on the order row
- Webhook endpoint that verifies the request and updates status
- A retry button for staff on failed rows
- A tag for the message type, such as invoice or OTP
Who edits the wording
With SMTP, the wording lives in your code or your own template files. A change to a footer line means a developer, a commit and a deploy.
With the API you can reference a template built in the Brevo editor. Staff in sales or accounts change the greeting, the bank details block or the unsubscribe footer without touching the application. Your code only supplies parameters such as the customer name and the invoice number.
Set a rule for who may publish a template. An unreviewed edit to an OTP message can break the code placeholder on a live site.
Failures: temporary against permanent
A temporary failure, such as a full mailbox or a busy receiving server, deserves a retry. A permanent failure, such as an address that does not exist, deserves none. Sending again to a dead address only harms your sender reputation.
SMTP reports these as reply codes in the 4xx and 5xx ranges, which your mail library may swallow. The API gives an HTTP status for your own call. Webhooks from Brevo report what became of the message later.
Build one rule in the application. Hard bounce means mark the address invalid and stop. Soft bounce means retry a few times, then flag the row for a person. Pick the API when you want that rule driven by clean events, and pick SMTP when you only need mail moving today.
Brevo send route decision sheet
Worksheet of one page with two columns, SMTP relay and API. Rows cover who builds the message, where the message ID is stored, who edits the template, the retry rule for soft bounces and the action on hard bounces. A last row lists webhook fields to save. Tick a column per row.
Open a blank worksheet to printQuestions owners ask
Can I start on SMTP and move to the API later?
Yes. Many teams switch the sending function behind one interface, then move message types over one at a time. Start with the mail customers wait for, such as OTPs and invoices.
Do both routes need the same domain authentication?
Yes. SPF, DKIM and DMARC records on your sending domain matter equally for both. Brevo shows the records it expects when you add the domain.
Which route handles attachments better?
SMTP takes attachments as part of the message you build. The API accepts them too, usually as encoded content or a link, so check the size you plan to send.
Where should the API key live?
In server configuration or a secrets store, never in the browser or a mobile app. Use a separate key for each environment so a test never sends to real customers.