The hard part of data sync is not moving fields between two APIs. It is deciding what should happen when both systems can change the same record.
One-way sync has a source and a destination. Changes move in one direction. Two-way sync lets changes in either system flow back to the other. That can reduce duplicate entry, but it also introduces conflicts, loops, identity problems, and deletion decisions that do not exist in a simple one-way feed.
The right question is not “do we want everything synced?” It is “which system is authoritative for each field, and what should happen when reality disagrees?”
When one-way sync is the better design
Use one-way sync when one system clearly owns the workflow. An EHR can own appointments while a messaging platform receives the appointment time and confirmation status. An accounting system can own paid invoices while an operations dashboard receives a read-only payment state. A product database can publish approved item details to an ecommerce catalog.
The destination can still use the data. It just should not send edits back for fields it does not own. This makes the direction easy to explain, test, and recover: rebuild the destination view from the source if needed.
One-way sync also limits blast radius. A bulk edit, compromised account, or bad automation in the destination cannot overwrite the system of record. That matters when the destination was chosen for communication or reporting rather than record governance.
Its main weakness is user expectation. If staff can edit a copied field in the destination, they may assume that edit will propagate. Either make those fields visibly read-only, hide them, or explain where the authoritative edit must happen. A technically correct integration still fails if the interface invites people to make changes that will be discarded.
What two-way sync actually requires
Two-way sync is appropriate when people must work in either system and both need current shared data. But “sync both ways” is not a complete specification. Define these rules before implementation:
- Record identity: how the same customer, property, invoice, or appointment is matched across systems.
- Field ownership: which system controls each field, including exceptions by workflow stage.
- Conflict policy: what happens when both copies change before the next sync.
- Deletion policy: whether deletion means archive, deactivate, unlink, or permanently remove.
- Loop prevention: how a write made by the integration avoids returning as a new business change.
- Recovery: how to replay failures without duplicating records or overwriting newer data.
Stable external IDs are safer than matching by email, name, or phone number. People share contact details, names change, and formatting differs. Where a platform supports it, upsert by an external ID lets the destination update an existing mapped record or create it when no mapping exists. Salesforce documents this behavior in its official upsert reference.
Field ownership beats record ownership
One system does not always need to own the whole record. A CRM might own lead stage and salesperson notes. A billing platform owns payment status. A scheduling system owns appointment time. The integration can assemble a useful shared view while preserving ownership field by field.
Write the contract as a matrix before writing code. For each synced field, name the source of truth, allowed destination edits, transformation rules, null handling, and conflict behavior. “Last write wins” is a policy, but it is often a poor default because clock differences and delayed delivery can make an older business decision look newer.
When an API exposes versions or entity tags, conditional updates can prevent accidental overwrites. HTTP's official specification describes using If-Match with entity tags to stop a write when the resource has changed since it was read. The integration can then re-fetch the record, apply its conflict rule, or send the item for human review instead of silently destroying someone else's update.
The failure modes teams discover late
Duplicate creation happens when system A creates a record, the callback is delayed, and system B independently creates what appears to be the same person. Without a stable correlation ID, both records can survive and multiply with each retry.
Sync loops happen when A updates B, B emits a change, and the integration writes the same value back to A. Comparing normalized values, recording the integration's write version, and ignoring no-op changes can stop the loop.
Partial failure happens when three of five field writes succeed. Retrying the entire operation may be safe for idempotent updates but dangerous if it also creates notes, tasks, or transactions. Track operations separately and design repeated execution to converge on the intended state.
Deletes are especially risky. A “deleted” contact may mean archived in one platform and irrecoverable removal in another. Default to a soft state such as inactive or archived until the business has explicitly approved destructive propagation.
Incremental sync state can expire too. Microsoft Graph notes that delta tokens have finite validity and that clients must be ready for replays and full synchronization resets. Its delta query overview is a useful example of why a two-way integration needs both normal change processing and a rebuild path.
A safer rollout sequence
Start with one entity and a narrow set of fields. Backfill existing records, produce a match report, and resolve ambiguous identities before turning on continuous updates. Run outbound changes in report-only mode first so the business can inspect what would have been written.
Then enable one direction, observe failures, and add the reverse direction only for fields that genuinely need it. Keep an audit log that answers: which source value was read, what transformation ran, what destination request was made, and what the API returned. A dead-letter queue without enough context to repair the record is only a second inbox.
The acceptance test should cover more than the happy path: simultaneous edits, duplicate webhook delivery, stale versions, missing required fields, expired credentials, pagination, deleted records, API throttling, and a full rebuild from source data.
How to choose
Choose one-way sync when one platform clearly owns the data, when the destination is primarily for reporting or communication, or when the cost of an incorrect write is high. Choose two-way sync when users have a legitimate need to edit shared fields in both systems and the business is willing to define conflict rules.
A mixed model is common: one-way for financial, clinical, or compliance-sensitive fields; two-way for selected contact details or operational status; no sync for private notes. That is usually more accurate than treating an entire record as universally writable.
Our systems integration service starts with this ownership and conflict model before connecting APIs. If the team also needs a controlled workspace that combines data without exposing every source system for editing, our custom development service covers internal dashboards and operator tools built around those boundaries.
