Delta Synchronization
Delta synchronization transfers only the records changed since the last sync between two systems – not the entire dataset.
Delta synchronization is a method for reconciling data between two systems in which each run transfers only the records created, changed or deleted since the last sync – the so-called "delta". The remaining, unchanged data is left out. Its counterpart is the full synchronization, which transfers every record on each run regardless of whether anything has changed.
In ERP integration, delta synchronization is the default mechanism whenever large volumes of data must be reconciled frequently and promptly between the ERP, online shop, marketplace, accounting or warehouse system. Because only changes are processed, transfer volume, compute load and runtime drop dramatically – often from hours to seconds. This is what makes short sync intervals, and thus near-current stock levels, prices and order statuses across all channels, economically feasible in the first place.
At a glance
- Transfers only changes (the delta) since the last sync, not the entire dataset
- Counterpart to full synchronization; considerably faster and more resource-friendly
- Requires a reliable change signal: timestamp, change flag, version number or event
- Enables short intervals and near real-time stock levels across multiple channels
- Must cleanly handle deletions, failed runs and duplicate processing
How does delta synchronization work?
At the core of every delta synchronization is the question: what has changed since the last successful run? To answer it, the source system must make changes detectable and the integration must remember the state of the last run. On the next pass, only the records that fall after that state are selected and handed over to the target system.
The point in time or marker of the last successful run is stored as a "high watermark" – for example the highest already-processed change timestamp or the highest version ID. Only records above this watermark count as the new delta. After a successful transfer, the watermark is advanced.
How is the delta detected?
In practice, several mechanisms are used: change timestamps (a "modified at" field per record), an explicit dirty or change flag, monotonically increasing version or sequence numbers, a change data capture evaluation of the database log, or event-driven signals such as webhooks that fire on every change. Timestamps are the most common but tricky when it comes to time zones, clock inaccuracies and concurrent writes.
How are deletions handled?
Deleted records are the classic blind spot: what no longer exists does not show up in a timestamp-based query. Solutions include the "soft" delete (soft delete with a deletion flag instead of physical removal), a separate deletion change log, or occasional full syncs as a reconciliation. Without such a precaution, orphaned records remain in the target system.
Why delta synchronization matters
The benefit lies in speed and scalability. A retailer with 80,000 items and several sales channels cannot push its entire catalog back and forth in full every few minutes – that would overload databases, APIs and compute time and hit API rate limits. If, on the other hand, only the 200 items whose stock or price has changed since the last run are transferred, the reconciliation completes in seconds and can be repeated as often as needed.
From this follows the real business value: current data. Short delta intervals keep stock levels across shop, marketplaces and ERP nearly in sync, reduce the risk of overselling and give customers reliable availability and status information. At the same time, load and costs drop in cloud environments where compute and transfer volume are billed.
Delta synchronization in the ERP system
In the ERP context, delta synchronization is spread across a multitude of integrations: item and price data flow to the shop, stock levels between warehouse and channels, orders from the marketplace into the ERP, posting documents to financial accounting. The connection is usually made via REST APIs, webhooks or a middleware or iPaaS platform that orchestrates the delta reconciliation, manages the watermark and logs errors.
Because delta runs can fail, be retried or run in an overlapping manner, idempotency is central: the same change may arrive multiple times without causing duplicate damage in the target system. This is achieved through unique keys and "upsert" logic (insert or update). Equally important is clean error handling – if a run fails midway, the watermark may only be advanced after confirmed processing, otherwise changes are lost.
One-way and bidirectional delta synchronization
A delta synchronization can run in one direction or in both. In the unidirectional variant there is a clear leading system (master) – for example the ERP for item and stock data – whose changes flow into one or more target systems. The model is simple and conflict-free because only one side writes and the other only reads.
In bidirectional delta synchronization, both systems change the same data, and each side transfers its delta to the other – for example when orders originate in the marketplace but status changes are maintained in the ERP. This inevitably raises the question of conflict resolution: if a record is changed on both sides between two runs, a rule must decide which version wins (such as "last change wins", field-level merging, or a defined system of record). Without such rules, both sides overwrite each other and the data diverges.
Distinction: delta vs. full synchronization
The full synchronization transfers the entire dataset on every run and overwrites the target completely. Its advantage is simplicity and self-healing: it needs no change signal, ignores past errors and establishes a defined overall state – ideal for the initial load, small data volumes, or as a regular consistency anchor. Its downside is the high effort, which rules out frequent runs.
Delta synchronization, conversely, is efficient but more demanding: it presupposes correct change detection and can silently diverge with faulty watermarks or unhandled deletions. In practice, you combine both – frequent delta runs for ongoing operation plus a periodic full sync (nightly, say) as a safety net against drift. The term differs from pure stock synchronization in that a delta describes a general transfer pattern for any kind of data, not just stock levels.
Common pitfalls
Delta synchronization is conceptually simple but error-prone in the details. Timestamp-based deltas lose records when clocks are not in sync or when changes fall exactly on the watermark – a small time buffer (overlap) when querying helps, but produces duplicate processing, which in turn requires idempotency. If the watermark is set too early, changes from an aborted run are lost unnoticed.
Other classics are unhandled deletions, missing conflict resolution in bidirectional synchronization (which side wins on a simultaneous change?) and the silent drift over weeks that only a full sync uncovers. Robust integrations therefore rely on monitoring, retryability, deletion signals and regular reconciliation runs instead of blind trust in the delta.
Example
Example: stock reconciliation of a multichannel retailer
An online retailer with 60,000 items sells via its own shop and two marketplaces. The ERP holds the master stock. Instead of transferring all stock levels in full every minute, a delta reconciliation runs every 60 seconds: the integration asks the ERP for all items whose stock has changed since the last timestamp. Usually that is only a few dozen – those for which orders have just come in or goods receipts have been posted.
Only these changes travel via API to the shop and marketplaces. As a result, availability stays nearly current everywhere, overselling is avoided and the marketplaces' API rate limits are not blown. Once a night, a full sync also runs, checking whether a stock level has drifted apart unnoticed anywhere and smoothing out discrepancies.
Frequently asked questions
Related services
Sources
Questions about Delta Synchronization in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.