API integration for Brevo
We build your Brevo connector
We wire the Brevo API into your business events to the Brevo API to send your transactional emails and text messages, sync your contacts and cut off sending to a dead address from the first rejection.
- Senior product team
- email and SMS connectors in production
- from scoping to monitoring
What does the Brevo API do and when should you integrate it into your application?
Brevo is a French transactional email and marketing automation tool. Its API lets you send emails triggered by events in your product: order confirmation, follow-up, alert, and synchronise contacts with their business attributes to personalise campaigns. You integrate Brevo when lifecycle emails need to move out of the application code so the marketing team can manage them, or when product behaviour should automatically trigger a sequence without manual intervention.
What our clients build on the Brevo API
Lifecycle emails driven by templates
Activation, invoice, failed payment, password reset: the content lives in Brevo, your code only sends the business variables.
Automatic list hygiene
A hard rejection or a complaint flags the address in your product and cuts off later sends. Your sender reputation stops eroding.
Contacts synced both ways
Product attributes feed the marketing segments, and an unsubscribe made inside Brevo comes back down into your application.
Automations triggered by the product
Trial ending, usage threshold reached, a feature never opened: the event leaves the product within seconds, with no daily import.
What it changes in how you communicate
Engineering in service of a measurable outcome: emails that land, a clean list, a marketing team that runs on its own.
Marketing keeps its templates
The content changes inside Brevo, with no developer and no release involved. Your code only sends the variables.
Your emails actually land
The Brevo code, DKIM and DMARC records are treated as a project deliverable. Without them your sender address gets replaced.
A list that does not rot
Invalid addresses leave the loop from the first hard rejection. You stop paying to send into the void.
One account for email and SMS
Billing, reporting and unsubscribes are pooled. There are not two vendors to reconcile at the end of the month.
How we ship your Brevo connector
Scoping
Which messages, what volume, which templates, which contact attributes. We settle the direction of the sync before coding.
Development
Typed connector, application-level idempotency, template and list caching, retry queue. A demo every week.
Acceptance testing
DNS verified before the switch, rejection and complaint webhooks replayed, the STOP keyword checked inside the final SMS content.
Monitoring
Alerts on the rejection rate and on send failures, DMARC report monitoring, an inspectable dead letter queue.
What the Brevo API allows
- Transactional email by template
- Sending by template id with mustache variables, tags, custom headers and scheduled delivery, with a message identifier returned each time.
- Transactional SMS
- An alphanumeric sender of 11 characters or a numeric one of 15, an international recipient, unicode content and event reports.
- Contacts, lists and events
- Syncing contacts and their attributes, managing lists, and publishing custom events that trigger an automation.
- Deliverability webhooks
- Twelve events, from Sent and Delivered through Hard Bounce, Complaint, Blocked or Unsubscribed, tied to the message identifier.
The vocabulary of the Brevo API
- messageId
- The identifier returned on every send. It is the key that ties an email or a text message to the deliverability events received afterwards: without it stored on your side, a webhook attaches to nothing.
- params
- The object of variables injected into a template through mustache syntax. It keeps the content with the marketing team and the business data inside your application.
- batchId
- An identifier that groups related sends, for instance to handle them together. It is not an idempotency key: it does not protect against a replay that sends and bills twice.
- [STOP CODE]
- The token substituted into SMS content to insert the unsubscribe mechanism. The substitution requires declaring the marketing type, which is surprising on a transactional endpoint.
- Hard Bounce
- The permanent rejection of an address. Handled through a webhook, it flags the address in your database and cuts off later sends, which protects your sender reputation.
- DKIM and DMARC
- The two DNS records that prove you really are the sender, alongside the Brevo code. Without them the domain is not authenticated and the displayed address gets replaced.
The real constraints of the Brevo API
The quota that breaks you is not sending
Email sending absorbs 1,000 requests per second, but the remaining endpoints are capped at 100 requests per hour on the general tier. Reading a template or a list on every user request breaks in production.
No HMAC signature on the webhooks
The documentation provides neither a signature header nor a shared secret: only IP ranges, a bearer token and custom headers. So an event never counts as authorisation, the state gets re-checked.
The transactional SMS type is a trap
For the unsubscribe token to be substituted, the documentation asks you to declare the marketing type on the transactional endpoint. Setting transactional by reflex produces messages with no working STOP.
Domain authentication is a deliverable
Three DNS records are required: the Brevo code, DKIM and DMARC. Without them Brevo temporarily replaces your sender address, which breaks brand alignment and often breaks replies too.
Brevo or Twilio for your sends?
A French email and SMS suite on one side, a programmable carrier on the other. The right one depends on which channel carries your volume.
| Criterion | BrevoThis page | TwilioProgrammable carrier |
|---|---|---|
| Channels covered | Email, SMS, WhatsApp, chat | SMS, MMS, WhatsApp, voice |
| Transactional email | Core of the product, templates included | Outside the scope of this page |
| Vendor | France | United States |
| Webhook signature | None: IP ranges and a token | X-Twilio-Signature in HMAC-SHA1 |
| OTP out of the box | To be built in the application | Verify: SMS, voice, TOTP, passkeys |
| What breaks in production | The 100 requests per hour on other endpoints | Throughput per sender type |
| The right case | Email carries most of the volume | Voice, OTP and multichannel |
The two combine: Brevo for lifecycle email, Twilio for voice and identity verification. It is a scoping trade-off, not a permanent choice.
What we measure on a Brevo integration
The other sending APIs
If email is not the main channel, these options are worth discussing during scoping.
BrevoWe build your Brevo connectorThis page
TwilioA programmable carrier: SMS, WhatsApp, voice and OTP out of the box.
RingoverFrench telephony: calls, screen pop and SMS from your business software.
MailjetEmail at volume, a French vendor, a straightforward API to wire up.
ResendWe build your Resend connectorWe combine Brevo with
The stack that surrounds Brevo on our projects.
Brevo integration: your questions
Three steps. Generate one API key per environment and per service, passed in the api-key header and kept in a secret manager. Build a connector that sends by template with an idempotency key held in your own database, caches templates and lists so it never hits the 100 requests per hour ceiling, and records the message identifier that comes back. Then wire up the deliverability webhooks to flag rejected addresses and propagate unsubscribes. The sensitive part is not the send itself, it is domain authentication and the state of your address base.
A first useful flow, typically transactional emails by template with delivery tracking, ships in two to three weeks. A complete chain with two-way contact sync, product events, compliant SMS and a preference centre is closer to six to eight weeks. DNS configuration and the state of your address base often weigh more than the engineering. We scope the perimeter up front and give a firm estimate before we start.
Through defence in depth, since authenticity cannot be proven cryptographically. We restrict the entry point to Brevo's IP ranges, declare a high-entropy bearer token or custom headers when the webhook is created, expose an unguessable URL and validate the payload schema strictly. Above all, an incoming event never counts as authorisation: before any side effect, the state is re-checked through the API or in the database. Events are deduplicated and processed asynchronously, with every rejected payload logged.
Because the type parameter was most likely left on transactional. For the unsubscribe token to be substituted into the content, the documentation asks you to declare the marketing type, including on the transactional SMS endpoint. It is counter-intuitive, and it is the most common mistake on this topic. So we add an automated test that checks the unsubscribe keyword is really present in the final content, and we classify every message as transactional or marketing in the database, which also drives the French sending window from 08:00 to 21:30.
Brevo brings transactional email, SMS and chat together in a single account, with templates maintained by the marketing team: it is the right choice when email carries most of the volume. Twilio is a programmable carrier, better as soon as you need voice, multichannel or a ready-made two-factor authentication building block. Brevo is also a French vendor, which is a favourable point in a discussion about where processing happens; the exact scope gets checked against the data processing agreement in force, not against a marketing page. We settle it during scoping.
A Brevo integration project?
Let's talk. 30 minutes to scope your sends, check what the API actually allows and tell you honestly what is feasible.
Discuss my Brevo project