How it works
Four mechanisms, in the order a product goes through them.
1. Matching, before anything is copied
The first check reads both catalogues and matches products by SKU, then barcode, then handle. A match creates a link that survives later edits: renaming a SKU afterwards does not break the pair, because the link is stored as a hidden identifier on the destination product, not as a guess recomputed every day.
When two products match ambiguously - same handle, different SKUs - StoreTwin refuses to decide and puts the pair in Needs review. Silent guessing is exactly how sync apps create duplicate products.
2. Writes, one way and only after two approvals
A connection starts in checking-only mode: it reads and compares and copies nothing. You allow changes, then start syncing - two separate, deliberate presses. Only the destination store is ever written to; the source is read-only for the app.
Products missing in the destination store are created with their variants, options, images and stock. Products already linked are repaired field by field. Nothing is ever deleted.
3. Echo suppression, so the loop stays closed
Our own write comes back as a webhook. Naive apps suppress that with a timer, which silently drops merchant edits that arrive in the same moment. StoreTwin instead records what it expected to write and compares the incoming state against that expectation, field by field. If the change is exactly ours, it is an echo; if a merchant edit rode along with it, the app sees the difference and reconciles.
4. The audit, hourly and daily
Hourly, StoreTwin re-checks products that changed since the last pass, reading by a cursor so nothing is lost if a webhook was missed. Once a day, it exports the full catalogue of both stores in bulk and compares them field by field: titles, descriptions, status, tags, options, variants with SKU, barcode and weight, your product metafields in the custom namespace, images and stock per location.
The result is a list of differences - the product, the field, the value on each side. When the connection is syncing, the difference is repaired and the next report says In sync.
Inventory, per location and not by totals
Stock is compared as the sum of the source locations you selected against one destination location you selected. Store totals would hide the common failure: right total, wrong warehouse. Updates are written as a set with a compare-and-swap against the value we last read, so a sale landing mid-write cannot be overwritten blindly.
Guardrails
A connection that starts writing far more than usual pauses itself and tells you why, instead of grinding through your catalogue. A pace pause lifts itself after a minute, then five, then fifteen, up to an hour, and clears once the store goes quiet - nothing is pressed. The one stop that waits for you is a batch of stock updates where most counts would become zero. Every write is journalled with what it was expected to produce, and that journal is what support answers from.