Loading tutorials…
Loading tutorials…
Transactional email — order receipts, password resets, signup confirmations — has a higher deliverability bar than marketing. Recipients EXPECT it within seconds. Brevo's transactional product (formerly Sendinblue SMTP) is genuinely good, but the setup hides reputation traps that brick your sends if you mix marketing and transactional under one stream.
Who this is forOwners running a SaaS, e-commerce store, or any app that sends triggered emails (receipts, password resets, signup confirmations, shipping notifications). If you currently send these through Gmail SMTP, your own server, or a free SendGrid trial, this is the upgrade.
What you'll need
Step 1
Brevo top menu → Transactional → activate. Free plan includes 300 transactional/day combined with marketing; upgrade to paid Transactional plan for separate tracking and higher limits.
Brevo top menu → click "Transactional" → if not enabled, click "Activate."
Decide plan: Free includes 300 emails/day TOTAL (marketing + transactional combined). Transactional add-on ('Brevo for Developers' or 'TIPs') starts at $15/mo for 20K/month with separate reputation tracking.
Most e-commerce stores need the paid add-on by week 2 because order receipts + password resets alone push past 300/day at modest scale.
Verify the Transactional sub-dashboard appears with sections: Statistics, Logs, Templates, Settings, SMTP & API.
Step 2
SMTP for simple integrations (existing app SMTP config). API for custom apps + better error handling. Most modern stacks should use API.
SMTP: works with anything that supports SMTP (WordPress plugins, e-com platforms, legacy apps). Slower, less error visibility. Use for: simple WordPress sites, basic e-com plugins.
API: REST API, better error handling, supports templates with dynamic data. Faster. Use for: custom apps, modern frameworks (Node, Rails, Django, Next.js, Laravel), Shopify apps.
Recommendation for 2026 stacks: API. SMTP is fine but you give up batch sending, async confirmation, and structured error responses.
If you're not sure — pick the one your developer is more comfortable with. Both deliver the same result on Brevo's infrastructure.
Step 3
Transactional → SMTP & API. Generate credentials for your app. Store as environment variables, never in code.
Transactional → SMTP & API → SMTP tab.
Note the credentials Brevo provides: SMTP server (smtp-relay.brevo.com), port (587 TLS or 465 SSL), login (your Brevo account email), password (a generated SMTP key — NOT your account password).
For API: click API Keys tab → Create a new API key → label it 'Transactional - Production' (or similar). Copy the v3 API key — Brevo only shows it once.
STORE THE KEY SECURELY: environment variable (BREVO_API_KEY=xkeysib-...) in your app's secret manager (Vercel env vars, AWS Secrets Manager, Heroku config vars). NEVER commit to git.
Create a SECOND key labeled 'Transactional - Staging' for your staging/dev environment. Production credentials must not be reused in staging.
Step 4
Use a DIFFERENT sender address than marketing — e.g., orders@yourbrand.com or notifications@yourbrand.com. Isolates reputation.
Senders, Domains & Dedicated IPs → Senders → Add a sender.
Use a sender like 'orders@yourbrand.com' or 'notifications@yourbrand.com' — NOT the same address you use for marketing campaigns.
Verify it (same flow as before — Brevo emails a verification link).
Why separate: if a marketing campaign triggers high complaints (e.g., spam-folder placement), it damages reputation for that sender. Keeping transactional under a different sender means order receipts keep landing in primary inbox even if marketing reputation dips.
Configure the sender in your app code: the From address on transactional API calls = orders@yourbrand.com.
Step 5
Transactional → Templates → Create a new template. Build each transactional email once; reference by ID from your code.
Transactional → Templates → Create a new template.
Name it descriptively: 'Order Confirmation,' 'Password Reset,' 'Welcome Email,' 'Shipping Notification.'
Use the drag-drop editor or paste HTML if you have a designer's version. Use {{ params.variable_name }} syntax for dynamic data (e.g., {{ params.order_number }}, {{ params.first_name }}).
Save the template. Brevo assigns a Template ID (e.g., #42). Note this ID — your code references it.
Repeat for every transactional email your app sends. Common list: order confirmation, shipping notification, password reset, welcome, payment failure, refund.
Test render each by clicking 'Preview' and filling sample variables.
Step 6
Replace existing SMTP/transactional-send code with Brevo. Most platforms (Node, Python, PHP, Ruby) have official Brevo SDKs.
Install the Brevo SDK for your language: `npm install @getbrevo/brevo` (Node), `pip install sib-api-v3-sdk` (Python), `composer require getbrevo/brevo-php` (PHP).
Initialize with your API key (from env var, not hardcoded).
Example call structure: `sendTransacEmail({ to: [{email: customer@example.com, name: 'Jane'}], templateId: 42, params: { order_number: 'ORD-1234', first_name: 'Jane' } })`.
Handle errors: API returns 4xx for bad data, 5xx for Brevo issues. Log failures + retry once after 30 seconds for transient errors.
Replace ALL existing transactional sends — order confirmations, password resets, welcome emails. One stream, one platform.
Step 7
Transactional → Logs shows every send. Set up alerts via Brevo webhooks for bounce/complaint events.
Transactional → Logs. Verify your test sends appear with status 'Delivered.'
If status shows 'Soft bounce' or 'Hard bounce,' the recipient address is bad. Hard bounces are auto-suppressed by Brevo (won't retry).
Set up webhooks: Transactional → Settings → Webhooks. Configure URL endpoints in your app to receive: delivered, bounce, complaint, open, click events.
Send the webhook to a monitoring endpoint that pages your team if bounce rate exceeds 5% or complaint rate exceeds 0.3% in any hour.
Run a daily check: how many transactional sends? How many delivered? How many bounced? Variance > 20% from normal = investigate.
Common mistakes
Sharing the sender between marketing and transactional
What goes wrong: One bad marketing campaign tanks reputation, and order receipts start landing in spam. Support tickets spike 30-50% with 'where's my receipt?' Customer trust drops. Hard to diagnose because Brevo shows 'delivered.'
How to avoid: Use TWO sender addresses: news@yourbrand.com for marketing, orders@yourbrand.com for transactional. Brevo tracks reputation per sender — isolating limits the blast radius.
API key in client-side code or committed to git
What goes wrong: Public API key = anyone can send unlimited mail through your account. Worst-case: spam floods your daily limit, account suspended, transactional sends stop. Cost: $500-5,000 in emergency consulting + service interruption.
How to avoid: API key in server-side env vars only. Use `.env` files locally + secret manager in production. If a key leaks, immediately revoke in Brevo → API Keys → revoke + create new key.
No retry logic on API failures
What goes wrong: Brevo API has 99.9%+ uptime but transient 5xx errors happen. Without retry, those sends silently fail. Customer doesn't get a receipt and assumes the purchase failed. Support gets 'I didn't get a confirmation' tickets.
How to avoid: Wrap API calls in try/catch. On 5xx error, retry once after 30 seconds. On 4xx (bad data), log + investigate — don't retry blindly. Use a job queue (Sidekiq, BullMQ, Celery) for retry orchestration.
Not migrating off old SMTP (Gmail, custom server, SendGrid free)
What goes wrong: Old SMTP runs in parallel for 'safety' — customers get duplicate receipts. Each platform sees only partial reputation signal. Multi-month low-grade deliverability drag.
How to avoid: Migrate ALL transactional in one cutover window. Test in staging, deploy to production, monitor for 24 hours, decommission old service. Don't run both "for safety" — pick one and trust it.
Generic FROM address on every template
What goes wrong: Using 'no-reply@' for every transactional template means customers can't reply to ask about their order. Support tickets shift to chat/phone, increasing cost. Replies bounce, frustrating customers.
How to avoid: Use specific addresses by template type. orders@ for receipts, support@ for shipping/issues, hello@ for welcomes. Monitor inboxes (or auto-route to your support tool).
Skipping bounce + complaint webhook monitoring
What goes wrong: Bounce/complaint rate creeps up over months. By the time you notice via gut feeling ('feels like less mail is getting through'), reputation is already damaged for 30-60 days.
How to avoid: Webhook to your monitoring system. Page on bounce > 5% or complaint > 0.3% in any hour. Investigate root cause immediately when triggered.
Recap
Done — what's next
How to set up a Brevo account from scratch (sender, DKIM/SPF/DMARC, GDPR)
Read the next tutorial
Hand it off
Transactional email is where 'works on my machine' deliverability gaps cost real customer trust. A specialist will set up the separation, monitoring, and retry logic in 2-3 hours that DIY teams often take 30-50 hours to get right. Typical engagement: $400-700 at $14-16/hr including code integration support.
See specialist rates
Marketing = bulk campaigns to lists (newsletters, promos). Transactional = triggered, 1-to-1 emails based on user actions (receipts, password resets). Brevo charges them separately on the Transactional add-on. Transactional has stricter deliverability requirements but Brevo handles them by default.
Brevo: cheaper at low-mid volume (under 200K/mo), simpler dashboard, integrated with marketing in one platform. SendGrid: stronger at enterprise scale, deeper dev tools, better Twilio integration. For most stores under $1M revenue, Brevo is the right answer. SendGrid wins above 500K transactional/mo.
Yes — Free plan allows 300 emails/day combined (marketing + transactional). For e-commerce, you'll hit this in week 1-2. Paid Transactional add-on starts at $15/mo for 20K/mo with separate reputation tracking and higher daily limits.
Typically 1-5 seconds from API call to inbox under normal load. Spikes during high-volume periods (e.g., Black Friday) can push to 10-30 seconds. If consistently above 30s, file a support ticket — that's outside Brevo's SLA.
Yes — use {{ params.variable_name }} syntax in the template. Pass dynamic data via the API call's `params` object. Brevo's template engine supports basic logic too: {% if params.is_vip %} ... {% endif %}. Don't try complex logic — keep templates simple, do logic in app code.
Sends start failing with 'quota exceeded' errors. App should catch this and either retry next day (low-priority transactional) or escalate to a backup transactional service for critical sends. Best practice: alert when usage hits 80% of monthly quota with 7+ days remaining.
Brevo
Brevo's onboarding is friendly enough to lull you into skipping the decisions that actually matter — plan choice, sender-domain auth, transactional vs marketing separation, GDPR fields. Skip them and deliverability quietly tops out at 60-70%. This is the setup that doesn't rot.
Brevo
Brevo's automation builder is genuinely capable — split conditions, multi-channel (email + SMS), and event triggers. But the difference between an automation that runs and one that drives 25-40% of revenue is in the trigger logic, exits, and split branches. Here's the build that converts.
Brevo
If your Brevo open rate just dropped 5-15 points or your campaigns are landing in Promotions/Spam, you're seeing a deliverability problem — not a content problem. The diagnosis is methodical; the recovery takes 30-60 days. Here's the playbook.
Brevo
DIY Brevo is a great call — until it isn't. Email + SMS + transactional + CRM should drive 25-40% of revenue for online businesses on an all-in-one platform. If yours is at 10-15%, the gap is the platform isn't being worked. Here's the framework for when to hire.