Brevo

Brevo (formerly Sendinblue) connects over its API and its SMTP relay, and its transactional webhooks report what happened after the handoff: confirmed deliveries, hard and soft bounces, deferrals, blocks, and spam complaints. Those events power the delivered state, webhooks like mail.delivered and mail.bounced, and automatic suppressions.

Before you start

• A Brevo account with your sender domain authenticated. See Deliverability for what each record proves.
• From Brevo’s SMTP & API settings: an API key, and your SMTP login with an SMTP key. Brevo’s API key covers the API only; SMTP needs its own SMTP key, so the account needs both to carry both transports.

IP blocking (optional)

Brevo can block API and SMTP calls from IP addresses you haven’t authorized (Settings → Security → Authorized IPs). Mailway doesn’t publish its sending addresses yet, so keep blocking off for the keys you give Mailway. Two details from Brevo’s own guide that can switch it on without you noticing:

• API keys learn: Brevo authorizes the addresses that call the API, and after 30 days without a new one it switches blocking on by itself.
• Authorizing any address by hand also switches blocking on, for both kinds of key.

If Brevo starts refusing Mailway’s calls, the mail’s timeline shows Brevo’s refusal, and Mailway tries the project’s next provider, if it has one.

Add the account in Mailway

1. Add the provider.

   In the console, open Providers → New provider, pick Brevo, and fill in the API key, plus the SMTP login and SMTP key. Secrets are encrypted at rest. Mail that reaches Mailway’s SMTP relay goes on over Brevo’s SMTP server (smtp-relay.brevo.com); HTTP API and console mail go over Brevo’s API.

   Tip

   Keep the SMTP credentials and leave Send via on Auto. Without them (or set to API only), relayed mail can’t be handed over as-is, because Brevo’s API is structured-only. It then skips the account unless a project admin enables re-encoding on the attachment.

2. Attach it to a project.

   Open the project, attach the provider, and position it in the failover order. Send something, and the provider health panel starts filling in.

Delivery events

Without delivery events, Brevo only reports that it accepted the mail. With them, Brevo tells Mailway what happened afterwards.

Brevo doesn’t sign its webhooks, so Mailway protects the URL two ways: Brevo logs in with a username and password Mailway generated for this provider, and Mailway checks that each request comes from Brevo’s published address ranges.

1. Open delivery tracking. In the console, open the provider → Delivery tracking (beside Configure). Mailway creates the provider’s webhook URL and shows it with a username and password. Treat the password like any other secret. Regenerating (at the bottom of the dialog) rotates the credentials and revokes the old ones instantly, so update Brevo afterwards.

2. Add the webhook in Brevo. Settings → Transactional emails → Webhook → Add webhook, then choose Outbound webhook:

   • Name: Mailway.
   • URL: paste the URL.
   • Authentication method: Basic. Paste the username and password, then Continue.

3. Pick the events. Event category: Transactional email. Brevo selects every event. Keep Delivered, Hard Bounced, Soft Bounced, Deferred, Blocked, Invalid, Error, and Complaint, and switch the rest off. Sent, the opens, Clicked, Loaded by proxy, and Unsubscribed aren’t delivery outcomes, and Mailway ignores them. Save.

What each event does in Mailway

Brevo event	Mailway outcome
Delivered	The mail turns delivered (confirmed by the provider’s event).
Hard Bounced	The mail turns bounced; the address is auto-suppressed for the project.
Soft Bounced	Recorded as soft_bounced (temporary; a later delivery outranks it).
Deferred	Recorded as soft_bounced (temporary; a later delivery outranks it). Brevo is still retrying.
Blocked, Invalid, Error	Recorded as dropped: Brevo didn’t attempt the delivery. The mail keeps its state.
Complaint	The mail turns complained; the address is auto-suppressed.

Note

Every Brevo event carries the message’s Message-ID. For API sends it’s the id Brevo returned at handoff. For SMTP sends it’s the Message-ID header your app set, which Brevo keeps. Both transports correlate exactly (verified live). Mail your app relays without a Message-ID header gets one from Mailway when Mailway receives it, so it correlates too (tested in 2026 Q4). An event only ever affects mail your own team sent through that provider. An uncorrelated event is still recorded and visible, just not pinned to a specific mail.

Check the connection

• Connection check. The provider page’s connection check logs in over SMTP and makes one read-only API call, without sending anything.
• Delivery events. Send a test email from the Delivery tracking dialog’s last step: it waits for Brevo’s first event and ticks when it arrives. After a real send, the mail’s timeline shows the delivered or bounced step with Brevo’s own details attached.

What Brevo changes

Mailway hands Brevo the message your app sent, byte-for-byte apart from the automatic exceptions, and archives it with the same exceptions made on receipt. Brevo then inserts its own open-tracking pixel into the HTML and routes every HTML link through its click tracker. A text-only message is delivered as HTML, with the text part replaced. Brevo also adds a List-Unsubscribe header. It does this over SMTP and over the API, by default. Any DKIM signature your app applied no longer verifies, while Brevo signs with its own DKIM for your domain. Brevo offers anonymized tracking and per-contact tracking consent in its settings. Tested results: What providers change.

Limits

Your Brevo plan’s own sending limits apply. Mailway adds none for Brevo beyond your Mailway plan’s quotas.