Request early access

Share your first name and an email address or phone number. We will follow up with Tajo access details.

Tajo Team Beginner 12 min Updated Aug 14, 2026

Understanding Shopify Data Sync with Brevo

How Tajo's governed sync moves data one way from your source into Brevo: scheduled runs, consent that fails closed, idempotent writes, and a full audit trail.

Tajo moves data from your source system into Brevo through governed sync rules: human-approved, one-directional, run on a schedule, and logged end to end. This article explains what that means in practice and what it does not include.

Quick check This article assumes you have connected Shopify and Brevo and published at least one sync rule. If not, start with connecting Tajo to Shopify.

The Shape of a Sync

Every sync in Tajo is a sync rule: a reviewed, approved definition of exactly what moves and how. A rule has four parts you can inspect on its page under Connectors > Syncs:

PartWhat it does
Field mappingEach source field, the Brevo field it writes to, and any transform in between
Filter expressionEvaluated per record; records that do not match are skipped
CursorTracks how far syncing has progressed, so each run picks up where the last one stopped
Run historyEvery run, with records read, written, and failed, plus duration and status

Data flows one direction: from your source into Brevo. Tajo does not write data back to Shopify.

When Data Syncs

Sync runs happen in scheduled batches, or on demand when you trigger a run from the rule’s page. Tajo is not a real-time pipeline: a change in Shopify reaches Brevo on the next run, not within seconds. This is deliberate — batch runs are what makes every write reviewable, budgeted, and attributable to a specific run in the audit trail.

Each run reads new and changed records since the cursor, applies the filter, maps the fields, and writes to Brevo. The run record shows exactly how many records were read, written, and failed.

The Governance Guarantees

A sync rule cannot be published without a consent policy, and at run time a record without provable consent is not written. When consent cannot be established, Tajo refuses the write rather than guessing. The failure mode is always “too careful”, never “over-sent”.

Runs are idempotent

Every write carries a provenance key derived from the source record (built to be PII-safe), so re-running a sync — after a failure, a pause, or manually — does not create duplicate writes. It is always safe to run a rule again.

Everything is audited

Publishing a rule, every approval decision (with its written rationale), and every run are recorded in the audit trail. The approval that authorized a publication is bound to the exact rule version that was reviewed; editing the rule invalidates the approval, so the audit trail always reflects what was actually authorized.

Failures pause the rule

If several consecutive runs fail, a circuit breaker pauses the rule automatically and surfaces the last error on the rule’s page. Fix the cause, then re-publish to resume. A partially failed run reports its failed count so you can see exactly what did not land.

How Unsubscribes Are Respected

Tajo treats Brevo as the source of truth for email consent:

  • When a contact unsubscribes via a Brevo email footer link, that opt-out is recorded against the contact, and Brevo excludes them from further campaigns.
  • Contacts blacklisted in Brevo stay excluded — downstream sends do not resurrect them.
  • Tajo does not push unsubscribe status back into Shopify. If you also collect email consent in Shopify, manage it there separately; do not assume the two systems mirror each other.

What Data Is Available

What syncs depends on the templates available for your source. For Shopify, the typical shape is customer records — identity fields, and order-derived attributes such as total spent and order count — mapped into Brevo contact attributes you can use in segments and campaigns. The exact mapping for your workspace is not hidden in a description: open the sync rule and read the field mapping table. That table is the authoritative answer to “what syncs”.

What Tajo Does Not Do Today

Being precise about the boundaries matters more than a long feature list:

  • No bi-directional sync. Nothing is written back to Shopify — not unsubscribes, not tags, not engagement scores.
  • No real-time sync. Runs are scheduled or manually triggered batches, not sub-minute streaming.
  • No inventory tracking. Product stock levels are not monitored, and there are no back-in-stock triggers.

If one of these boundaries blocks a use case for you, tell the team — early access priorities are shaped by exactly this feedback.

Where to See Your Data

  • In Tajo: open the sync rule under Connectors > Syncs for run history, cursor position, and per-run counts. The audit trail records publications and approvals.
  • In Brevo: open Contacts and inspect any contact’s attributes to confirm mapped fields are populating. Build segments on those attributes for targeting.

Troubleshooting

  • Contacts not appearing in Brevo: check the rule’s latest run for failures and its status (a paused rule is not running). See contacts missing in Brevo.
  • Runs failing repeatedly: the circuit breaker will pause the rule and show the last error. See data not syncing.
  • Duplicate contacts: writes are idempotent per source record, but pre-existing duplicates in Brevo stay. See duplicate contacts.

Common Questions

Can I make the sync faster? You can trigger a run on demand at any time from the sync rule’s page. There is no real-time mode.

What happens if a run fails halfway? The run reports its failed count, the cursor only advances over what was processed, and the next run safely re-covers the ground — idempotency keys prevent duplicates.

Can I change what syncs? Yes — edit the rule’s field mapping or filter. The edit produces a new version that must go back through publish approval before it takes effect.

Why did my rule pause itself? Consecutive run failures trip the circuit breaker. The rule’s page shows the failure count and last error; fix the issue and re-publish.

Get Help