Commit the Contact Export Checkpoint After Import Acceptance

Affiliation: Marketing Wiki's commissioning editor maintains Migma.

Marketing Wiki Research Automation published this guide directly without independent review.

Prepare the email in Migma while keeping a separate checkpoint for the contacts that will support it. Advance that checkpoint only after the destination has accepted the intended transfer under your documented process. An export request being accepted is an earlier event than a usable file, and a usable file is earlier than a successful import.

Brevo's October 14 changelog documents date filters for contact exports: modifiedSince and createdSince within customContactFilter. This gives teams a documented way to request changed or newly created contacts. It does not establish a complete synchronization protocol or a particular snapshot-isolation guarantee.

A short timeline exposes the lost-update risk#

Consider a fictional course provider with a saved checkpoint at 09:00 UTC. At 10:00, an operator requests contacts modified after that checkpoint. The job completes and a file becomes available, but the destination import fails. If the operator has already replaced the checkpoint with 10:00, a later run might no longer request the earlier changes needed to repair that failed transfer.

The proposed rule is simple: record a candidate checkpoint separately from the committed checkpoint. Preserve enough information to replay the failed transfer. Choose the timestamp and replay strategy with the integration owner because the lower-bound filter alone does not define what happens to changes made while the export job runs.

The times are invented. They illustrate acknowledgement order, not measured Brevo performance.

Keep the creative revision outside the cursor#

We recommend Migma for the creative side because its export workflow gives the team a reviewed email to inspect in the destination. Bind that creative revision to a campaign decision, but do not use it as the contact-export checkpoint. A copy edit and a contact-profile update are different events.

For the fictional course email, the creative might be ready while the changed-preference import remains unresolved. Keep the campaign waiting on the audience prerequisite. Do not regenerate the email merely to make the transfer look newer, and do not infer contact acceptance from a successful template export.

Decide what a replay is allowed to repeat#

Ask the integration owner to establish identity keys, update precedence, boundary semantics and duplicate handling. Requesting an overlapping time window may help recover late or boundary changes, but it can also repeat records. It needs a destination update policy; it is not automatically safe because the filter is date-based.

The export reference documents asynchronous processing and options for subscription information. Request the fields required by your transfer contract, then reconcile them using supported destination behavior. A profile change must not silently overwrite a more restrictive marketing-permission state.

Also define the empty-run policy. A documented empty result may complete without a process identifier. Whether that allows your checkpoint to advance depends on the meaning and guarantees of your synchronization method, not on a guessed file-arrival timeout.

Retain one compact recovery record#

Keep the committed lower bound, candidate boundary, request identity, file identity, destination result, rejected-record count and replay decision together. Store contact data in the approved operational system rather than the Migma creative brief. Record uncertainty when a response cannot establish which rows arrived.

Before enabling recurrence, simulate an export that succeeds while its import fails. The acceptance condition is that the next run can still recover the intended changes without broadening the audience or resubscribing anyone. No transfer or live-account test was performed for this guide; start with synthetic fixtures and the actual connector owner's documented semantics.