Zintara integration reconciliation: detect missing and conflicting state

Define the decision

Reconciliation asks whether two systems agree on the fields and scope they are supposed to share. It is separate from replaying every event. Zintara’s current webhook envelope does not provide a durable event log or stable event ID.

Work through the procedure

1. Define the exact entities and fields each system owns.
2. Fetch supported data with workspace-bound read scopes and recorded pagination boundaries.
3. Compare stable identities and retain differences in a review queue.
4. Apply only approved repeat-safe corrections.
5. Report unresolved gaps and the time covered by the pass.

Worked example

The following is a synthetic example for this procedure, not a customer result or performance benchmark.

Reconciliation result: 120 source leads checked
3 destination records missing
2 status conflicts requiring review
0 automatic re-enrollments
Completion means the comparison ran, not that every conflict was safe to resolve automatically.

Read the result

A useful report separates missing data from conflicting meaning. An absent reply notification cannot be repaired by guessing that the lead never replied, and a lead-list API may not expose every desired inbox fact.

Check before moving on

1. Check source capability before promising completeness.
2. Deduplicate paginated records by identity and account for concurrent changes.

Limits and next action

Keep destructive or sending-related corrections behind an explicit review decision. Reconciliation should not turn a transient mismatch into repeated contact.

Source: Zintara implementation and product context