How it works

1. Matching, before anything is written

The first scan 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 night.

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 audit mode: reads and compares, writes nothing. You enable writes, then start the sync - 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 nightly

Hourly, StoreTwin re-checks products that changed since the last pass, reading by a cursor so nothing is lost if a webhook was missed. Nightly, it exports the full catalogue of both stores in bulk and compares everything: titles, descriptions, tags, options, variants, weights, barcodes, metafields, images and stock per location.

The result is a drift report - 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. Every write is journalled with what it was expected to produce, and that journal is what support answers from.