Brevo Connector Guide: Four Ways to Connect Brevo to Your Stack
How Brevo connectors really work: native plugins, iPaaS, an integration layer, or direct API. Pick the right one and survive production sync failures.
Search for “Brevo connector” and you get a scattered mix of marketplace plugins, third-party automation apps, and community modules. That is because “connector” is not one thing. It is a category that covers four genuinely different engineering choices, each with a different failure mode and a different owner when something breaks.
This guide defines what a connector is, lays out the four approaches honestly, and then spends most of its length on the part almost no article covers: what goes wrong once the connector is live and carrying real traffic.
What a Brevo Connector Actually Is
Strip away the branding and every Brevo connector is the same three components.
Transport. How data physically moves. In practice that means calls to the Brevo REST API in one direction, and Brevo webhooks in the other. Brevo splits webhooks into marketing and transactional types, configurable from the dashboard or through the create and update webhook endpoints, with a ceiling of 40 webhooks per account across both types.
Mapping. How a field in the source system becomes a field in Brevo. A Shopify customer has first_name; a Brevo contact has whatever attribute you defined, and Brevo silently ignores attributes that do not exist in your account. Mapping is where most connectors quietly rot.
State. What the connector remembers between runs: which records it has already sent, which failed, which cursor position it reached. Connectors without state cannot backfill, cannot replay a failure, and cannot tell you whether a contact is missing or just late.
Judge any connector by how well it handles all three. Most marketing pages only describe the first.
The identifier problem sits underneath everything
Brevo’s create contact endpoint requires at least one identifier: email, SMS, or ext_id, which is your own external identifier. By default a conflicting identifier returns a 4xx error. Setting updateEnabled to true turns the call into an upsert, and forceMerge merges duplicates by keeping the record with the most recent timestamp and deleting the other.
That single design decision, which identifier your connector treats as primary, determines whether you end up with a clean contact database or two of everything. Decide it before you pick a tool.
The Four Ways to Connect Brevo
Option 1: Native plugins and marketplace apps
Brevo runs an app marketplace it describes as connecting Brevo with “150+ digital tools like Shopify, WordPress, Stripe, Zapier and more”. Its featured first-party apps are WordPress, WooCommerce, Shopify, and BigCommerce, and the marketplace is filterable by category and by who developed the app, which matters more than it sounds: a Brevo-built app and a partner-built app carry very different support paths.
Strengths. Fastest path to working. Authentication, basic field mapping, and the common events are pre-wired. When Brevo changes its API, the vendor updates the plugin.
Weaknesses. You get the mapping the vendor chose. Custom attributes, unusual objects, and store-specific logic usually fall outside it. Debugging is limited to whatever the plugin logs, which is often nothing useful. And when a partner-built app is abandoned, you find out during an outage.
Use it when you have one standard platform, standard fields, and no requirement to prove what synced.
Option 2: General iPaaS tools
Zapier, Make, and Pabbly Connect all expose Brevo. Brevo embeds Zapier directly on its integrations page under the heading “Connect Brevo with your apps, automate your work via Zapier”. Make publishes a Brevo app whose modules cover watching, creating, updating, listing, and deleting contacts, lists, folders, campaigns, events, emails, and SMS. Pabbly Connect lists Brevo among its supported apps.
Strengths. Genuinely excellent for the long tail. A form vendor nobody has ever heard of, a one-off internal tool, an approval step that needs a human in the middle: iPaaS handles these in an afternoon, and a non-engineer can maintain the scenario.
Weaknesses. Per-task pricing punishes volume. Most scenarios are record-at-a-time, so a 40,000 contact backfill is either impossible or expensive. Error handling is usually “the run failed, here is an email”, with no automatic replay and no way to ask which of last Tuesday’s records never landed. Ordering is not guaranteed, so an update can overtake the create it depends on.
Use it when volume is low, the flow is one-way, and a dropped record is annoying rather than costly. Our roundup of the best integration platforms compares the options in that category directly.
Option 3: A purpose-built integration layer
A layer that sits between your systems and Brevo, owns the mapping and the sync state, and is built for this specific job rather than for any-app-to-any-app.
Tajo is one such option. It describes itself as an AI marketing team for Brevo that connects supported commerce data to Brevo, builds rule-based customer segments, and prepares governed email and SMS campaigns. Practically, the tradeoff of any purpose-built layer is the same: you accept an opinionated model of contacts, events, and campaigns, and in exchange you get backfills, retries, and per-record visibility that neither a plugin nor a generic iPaaS gives you. Our Brevo integration guide walks the setup end to end.
Strengths. Bulk operations are first-class. Failures are visible per record and replayable. Mapping is explicit and versioned rather than buried in a plugin.
Weaknesses. Another vendor in the path, and another thing to evaluate. If your requirement is one WordPress form posting to one Brevo list, this is heavy machinery for a small job. Be honest about that: a native plugin is the better call there.
Use it when commerce data volume is real, you need to prove what synced, and you want segments and campaign logic built on the same data model that the sync produces.
Option 4: Direct API integration
Your own code against the Brevo API.
Strengths. No ceiling. You control identity resolution, batching, retry policy, and audit logging exactly. For a data warehouse pushing modelled audiences into Brevo, this is often the only approach that fits.
Weaknesses. You own it forever, including the parts nobody scopes: retry with backoff, dead-letter storage, schema drift alerts, credential rotation, and a runbook. Teams budget for the happy path and then spend triple on everything else.
Use it when the logic is genuinely yours and the volume justifies it. Start from our Brevo API guide for endpoint-level detail.
The Decision Framework
Six questions decide it. Answer them before you look at any tool.
| Question | Native plugin | iPaaS | Integration layer | Custom API |
|---|---|---|---|---|
| Data volume | Whatever the vendor supports | Low, priced per task | High, batch-aware | Unlimited |
| Sync direction | Usually one-way in | One-way per scenario | One-way with defined owners | Anything you build |
| Latency need | Vendor’s choice | Minutes | Near real time | Your choice |
| Mapping complexity | Fixed fields | Simple, per scenario | Explicit and versioned | Arbitrary |
| Error handling | Often invisible | Alert on failure | Per-record retry and replay | Whatever you build |
| Who fixes it | The plugin vendor | You, in a visual editor | The vendor, with your visibility | You, at 2am |
The last row is the one people skip and then regret. A connector is a long-term operational commitment, not a setup task, so pick the option whose failure mode you can live with.
Sync Patterns That Decide Whether It Works
One-way versus two-way
One-way sync has one owner per field and is boring in the best sense. Two-way sync requires loop suppression, conflict resolution, and a tiebreak rule, and Brevo will happily emit a contact_updated webhook for a change your own connector just wrote.
Do not build two-way sync because it sounds more capable. Build a field ownership table instead: your ecommerce platform owns order data, your CRM owns lifecycle stage, Brevo owns consent and engagement. Sync each field in one direction only. If you truly need bidirectional movement on a field, add an origin marker to every write and drop inbound events that carry your own marker.
Polling versus webhooks
Webhooks are cheaper and faster but not guaranteed. Marketing webhook events include delivered, opened, click, hard_bounce, soft_bounce, spam, unsubscribe, contact_updated, contact_deleted, and list_addition. Transactional webhooks cover the sending lifecycle from sent and delivered through deferred, blocked, complaint, and error.
Two things to plan for. First, Brevo’s webhook documentation focuses on allowlisting Brevo’s published IP addresses rather than a payload signature, so treat the endpoint as unauthenticated by default and confirm anything consequential by reading the record back from the API. Second, no webhook system delivers everything forever, so pair webhooks with a low-frequency reconciliation poll that catches whatever slipped through.
Batch versus real time
Real time matters for triggers, which is why abandoned cart and welcome flows deserve event calls. It does not matter for a nightly attribute refresh.
Match the pattern to the rate limits. Brevo’s contacts endpoints and its POST /v3/events endpoint allow 10 requests per second on standard accounts, transactional email allows 1,000 per second, and every other endpoint is capped at 100 requests per hour. Professional and Enterprise accounts roughly double the first set. That 100 per hour ceiling on “all other endpoints” is the single most common surprise: a connector that reads lists or folders on every record will exhaust it before lunch and start collecting HTTP 429 responses.
For bulk work, use the import endpoint instead of looping. It accepts a file URL, a file body, or a JSON body up to 10MB with an 8MB safe limit, runs asynchronously, returns a processId, and calls a notification URL when finished.
Idempotency and identity
Brevo’s event endpoint takes an event_name, at least one identifier, optional contact properties, and optional event properties up to 50KB, and returns 204 on success. There is no documented idempotency key, so a retried call can create a duplicate event.
Build idempotency yourself. Derive a deterministic key from the source record and its version, store which keys you have sent, and check before sending. For contacts, choose one primary identifier, populate ext_id from your source system’s ID, and use updateEnabled for upserts so a retry updates rather than errors.
Designing a re-sync you can trust
You will need to re-sync. Design for it on day one.
- Make every write idempotent, so replaying is safe rather than destructive.
- Keep a cursor per object type, and store it outside the connector’s memory.
- Test the re-sync against a throwaway Brevo list before the real one.
- Leave
emptyContactsAttributesat its default of false during imports. Setting it to true tells Brevo that blank fields should erase existing values, which turns a partial export into permanent data loss. - Log a per-record outcome. “The job succeeded” is not an outcome when 400 of 40,000 records failed validation.
What Actually Goes Wrong in Production
Field mapping drift
Someone renames a Shopify metafield or adds a required checkout field. The connector keeps running and keeps reporting success, because Brevo ignores attributes it does not recognise. Weeks later a segment is quietly half-empty.
Mitigation. Snapshot the source schema and the Brevo attribute list, compare them on a schedule, and alert on difference. Also alert on a drop in non-null rates per attribute, not just on errors.
Duplicate contacts
The classic cause is two connectors with two identifiers: the store plugin creates contacts by email, an SMS flow creates them by phone, and one human becomes two records with split engagement history.
Mitigation. One primary identifier, enforced everywhere. Populate ext_id from your source system so you always have a stable join key. Use forceMerge as a deliberate cleanup step, understanding that it deletes the older record, not as a routine setting.
Sync loops
Connector A writes to Brevo, Brevo emits contact_updated, connector B writes back to the source, the source emits its own change event, and the cycle repeats. Rate limits usually surface this before you notice it yourself.
Mitigation. Origin markers on every write, plus a per-record change counter that trips an alarm above a threshold within a time window.
Rate limits and partial failures
Exceeding a limit returns 429. The dangerous case is not the 429 itself, it is a batch where some records succeeded and some did not, and the connector treats the whole batch as failed and replays it, or treats it as succeeded and loses the failures.
Mitigation. Retry with exponential backoff and jitter, honour any retry hint, and track outcomes per record rather than per batch. Send failures to a dead-letter store with the full payload so they can be replayed after a fix.
Silent data loss
The worst failures are the quiet ones: an import with a blank column and emptyContactsAttributes set to true, an attribute that no longer exists so its values evaporate, a webhook endpoint returning 500 for an hour with nobody watching.
Mitigation. Monitor counts, not just errors. Contacts created per day, events received per hour, attribute fill rates. A metric that goes to zero is the clearest alert you will ever get.
Two systems that disagree
Eventually your source says 18,400 active contacts and Brevo says 18,062. Without reconciliation you cannot tell which is right.
Mitigation. Run a scheduled reconciliation that compares counts and a sample of records by identifier, and produce a difference report. Fix the causes rather than repeatedly re-importing, because a re-import hides the mismatch without explaining it.
Common Connections in Practice
Ecommerce. Shopify and WooCommerce are the two heavyweights, and both have first-party apps in Brevo’s marketplace. The native path handles contacts and basic order data well. Custom line-item logic, subscription state, and loyalty tiers generally do not fit it, which is where a layer or custom code earns its place. Our Brevo Shopify integration guide covers that specific pairing in depth.
CMS. WordPress is the most common Brevo connection outside ecommerce, typically for forms, newsletter signup, and transactional email through Brevo’s SMTP. The plugin path is almost always correct here, since the data model is simple and the volume is low.
CRM and data warehouse. This is where connectors get hard, because both sides believe they own the customer. Use a field ownership table, sync one way per field, and consider pushing modelled audiences from the warehouse into Brevo lists rather than syncing raw records. See our Brevo CRM guide for how Brevo’s own CRM objects fit that picture.
Forms. The ideal iPaaS use case: low volume, one direction, latency-tolerant. Do not over-engineer it.
Getting It Right
Connector choice is mostly a question about operations rather than features. Every option can move a contact from A to B. They differ in what happens on the day the mapping drifts, the rate limit trips, or 400 records fail validation inside a 40,000 record import.
Work through it in this order:
- Write down which system owns which field. Everything else follows from this.
- Pick one primary contact identifier and populate
ext_idfrom your source system. - Choose the lightest option that survives your volume and your error-handling requirement, not the most capable one.
- Build the re-sync and the reconciliation report before you go live, not after the first incident.
- Monitor counts and fill rates, because silent loss is more common than loud failure.
Do those five things and any of the four approaches can work. Skip them and none of them will.