Back to the guides

PRACTICAL SOFTWARE GUIDE

Brevo contact imports: update records without erasing useful data

Treat an import as a controlled data change: define identity, test overwrite behavior and reconcile a small pilot before loading the full file.

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Decide whether the file creates or updates contacts

Brevo requires at least one supported identifier to create a contact, such as EMAIL, SMS, WHATSAPP, LANDLINE_NUMBER or EXT_ID. Its import guidance also distinguishes new contacts from updates: CONTACT_ID is generated by Brevo for a new record and should be included only when an existing contact is being updated. Choose the identity rule before cleaning columns. A file that mixes unreviewed identifiers can update a different record from the one an operator expected.

Build a reversible pilot

Use a small synthetic file before the production import. A useful pilot contains one new contact, one existing contact with a changed non-critical attribute, one duplicate row and one blank optional field. Use addresses and phone numbers reserved for testing. Record the expected result for each row before uploading it.

  1. Export or otherwise record the current values of the pilot contacts.
  2. Map every accepted column to an existing Brevo attribute or deliberately ignore it.
  3. Leave unrelated columns out of the file rather than mapping them speculatively.
  4. Run the pilot and compare each resulting contact with the expected table.
  5. Only then prepare the full file using the same headers and options.

Treat blank fields as a separate decision

Brevo exposes one setting to update attributes of existing contacts and another to import empty fields in a way that erases existing attribute data. These are materially different changes. If a source system uses blank to mean “unknown” while Brevo already contains a value, importing empty fields can turn an incomplete source row into a deletion. Keep this option off unless erasure is the intended, reviewed outcome.

A worked reconciliation example

Assume a fictional newsletter has contact demo-17 with language EN and customer type Partner. The incoming row changes language to FR but has an empty customer-type cell. The acceptance table should say whether language becomes FR and whether Partner remains. Run the pilot with the chosen update settings and inspect the actual record. This example explains the decision; it is not a measured product test.

Check consent and list placement

Attribute accuracy does not establish permission to communicate. Brevo tells importers to use legitimate contacts and confirm the opt-in conditions. Separately record the list or lists receiving the contacts and whether any channel is being blocklisted. After import, compare the accepted, rejected and duplicate counts with the source file and investigate the difference before scheduling a campaign.

Keep an import record

Retain the source filename, row count, mapping table, identifier choice, overwrite settings, operator and completion date. Do not retain unnecessary personal data in a general project note. The purpose of the record is to explain which fields could have changed and how to reverse an error using an approved source.

Sources and verification

Official documentation checked on 2026-10-29. Worked examples are hypothetical planning exercises, not measured product benchmarks.

Continue your evaluation

Practical guides for this topic

Put your tools to work.

Need help choosing or setting up your tools? Tell Koldia what you want to improve.

Discuss your project