Brevo integrations: choose a connection you can verify

Send the same test contact twice. If the second run creates another record or revives an unsubscribe, the connector has failed before volume enters the picture.

“We only need to connect the two apps.” That is a reasonable starting point. The missing detail is what the connection remembers after the first request.

Check three things before choosing software

Transport gets a request or event from one system to another. Mapping decides what the fields mean. State records which source version was processed, what failed, and which destination record belongs to it.

Write down one source, one destination and the fields needed for the first useful result. Assign an owner to each field. A sales system can own a lifecycle stage while Brevo owns the current email opt-out. One record does not need one owner for everything.

Four routes into Brevo

A native app

Check the Brevo marketplace for a maintained app and its publisher. Read the setup instructions for the actual fields and events you need. Marketplace presence alone does not establish a Tajo integration.

For Shopify, start with the documented Brevo PushOwl setup and migration path. Test its mapping before building a second connection. A native app may cover the whole task, but its supported fields and recovery controls are specific to that app.

An automation service

An automation service can receive a form submission, map fields and call Brevo. Check its actual replay controls, task costs and storage before choosing it. Neither low volume nor a visual editor makes a lost subscription acceptable.

For website signups, our Webflow guide separates an embedded Brevo form from a server-handled native form. Choose the route that preserves the submission and confirmation behavior you need.

An integration layer

Use a dedicated layer when several mappings, durable processing records or coordinated recovery justify another service. Ask to see the failed-record view and a replay of one rejected record. Do not infer those features from the category name.

Tajo is in early access. Bring a concrete source, destination and acceptance check to an integration review. Verify the available connector and execution path before relying on it. Documentation about a pairing is a starting point for that review, not proof that it is ready in your workspace.

Direct API code

Choose code when you need control over identity, transforms or recovery that the available routes cannot provide. You then own credentials, rate limits, saved processing state and the runbook.

Use the Brevo API guide for a contact write and its failure boundaries. If the source is a spreadsheet, the Apps Script example is a separate script route; it does not require a native Tajo Sheets connector.

Use the existing decision framework

Decision	Native app	Automation service	Integration layer	Direct API
Required fields	Check app mapping	Check action inputs	Inspect the proposed map	Implement the map
Record identity	Check matching rules	Configure matching explicitly	Review the identity contract	Store the destination ID
Recovery	Inspect app controls	Verify retries and replay	Demonstrate record-level recovery	Build and operate it
Volume and limits	Confirm vendor limits	Estimate tasks and limits	Verify the intended workload	Respect destination limits
Operational owner	App provider and operator	Scenario owner	Provider and sync owner	Your team

Which route covers your actual requirement?

1. The native app covers the fields and checks

   Use the native app

   Start with the documented setup.

2. A form or event needs a small mapped action

   Evaluate an automation service

   Verify confirmation and replay behavior.

3. Several mappings need coordinated recovery

   Evaluate an integration layer

   Ask for a demonstrated failure and replay.

4. The required transform is not supported

   Write the smallest API path

   Budget for its operation as well as its first run.

Prove the first sync with one record

Use an isolated destination and a contact you control. Keep campaign automation disabled while checking the data path.

1. Record the source ID, destination list, required attributes and current consent evidence. Create the required attribute types before writing.
2. Run once. Inspect the destination record, not only the job status. Check the actual values and marketing eligibility separately.
3. Replay the same source version. Expect one identity and no repeated confirmation or welcome message.
4. Change an ordinary field and sync again. Then leave a source field blank and verify the documented preserve-or-clear rule.
5. Record a later unsubscribe. Replay the older signup and confirm the opt-out still wins.
6. Simulate a rejected request. Keep its identity and outcome, recover that record, and inspect it before advancing the saved cursor.

This is an acceptance procedure, not a claim that every connector exposes the same controls. If a required check cannot be demonstrated, that is the gap to solve.

Keep retries from changing the meaning

Brevo’s contact endpoint accepts a source ext_id and supports updateEnabled. Matching is still your responsibility. Conflicting identifiers need review; forceMerge can delete a record and should not be a default recovery action.

Repeated data writes and repeated side effects are different problems. A contact may exist once and still receive two confirmation emails. Save a submission identifier and the outcome of each effect. A request timeout leaves an uncertain outcome; inspect the destination before retrying a send.

Read the current rate-limit table for each endpoint and account tier. Limits differ, and some routes have both hourly and per-second limits. Avoid copying one numeric ceiling into every operation.

Webhooks still need an owner

An event tells you that something changed. It does not resolve competing field owners or maintain a complete two-way sync by itself.

Authenticate the delivery with the method supported by the provider, persist valid work, and reconcile missed updates. When a connector receives its own update back, compare the recorded source version and intended field values before writing again. Do not assume every provider returns a custom origin marker.

For a new subscriber, follow the double opt-in guide before admitting the address to a marketing audience. A copied address is a data outcome. A confirmed, currently subscribed address is a different one.

The connection is ready when the second run is as explainable as the first.