Guides

How to sync inventory between two Shopify stores

Shopify has no native way to share stock between two stores. Here are the three methods that actually work, what each one costs you, and how to tell which one fits.

The short answer: Shopify cannot do this on its own. Two Shopify stores keep two completely separate sets of inventory, and there is no setting that joins them. You have three real options — export and import CSVs by hand, build something against the Admin API, or install an app that does it for you. Which one fits depends almost entirely on how often your stock moves.

Why Shopify does not do this natively

This surprises people, so it is worth being precise about. Shopify’s inventory model is built around one store with many locations. A location is a place that holds stock — a warehouse, a retail shop, a 3PL. Shopify tracks the quantity at each location, adds them up, and shows the total on the storefront. Locations inside one store are always consistent with each other, automatically, because they are all reading from the same table.

A second Shopify store is not a location. It is a separate account with its own products, its own orders, and its own inventory records. Nothing in the admin connects the two, and that is a deliberate architectural boundary, not an oversight.

Shopify Plus does not change this. Expansion stores — a Plus contract includes ten stores in total, one main and nine expansion — are separate stores with separate inventory. Shopify says so itself: “Store settings, products, collections, and inventory aren’t synced between stores.” If you sell the same physical stock through an expansion store, you still need something to keep the numbers in step.

Two things people reach for that do not solve it: Shopify Flow runs inside one store and cannot write inventory into a different store, so it can react to a stock change but has nowhere to send it. And Stocky, Shopify’s own inventory tool, shut down on 31 August 2026 without a store-to-store successor — it never did this job anyway.

Four guides sit next to each other here, and it is worth knowing which you are on. This one is the method: CSV, a custom build, or an app, and what each costs you. The others are which architecture — mesh versus hub and spoke, and the rules that hold it together; which routine — what happens daily, weekly and monthly once it is running; and expansion stores specifically if you are on Shopify Plus.

One scoping note before the methods: this page is about inventory quantities. Getting the products themselves into the second store is a separate job with separate tools, the layer-by-layer map of everything that can link between two stores is its own guide — and if the second store does not exist yet, the case for and against opening one is worth an honest pass first.

Method 1 — CSV export and import

Export the inventory CSV from store A, open it, and import it into store B. Shopify supports this out of the box, it costs nothing, and for some businesses it is genuinely the right answer.

It works when: your catalogue is small, your stock moves slowly, and a few hours of drift costs you nothing. A studio that makes 40 products in batches and restocks on Mondays can do this on Mondays.

It breaks when: you sell the same unit through both stores. The CSV is a photograph of a moment. Between the export and the import, both stores keep taking orders, and the file you just imported quietly overwrote quantities that had already moved. The faster you sell, the more the numbers lie — and the lie always points the same direction, because the file says you have more than you do.

There is a second, quieter problem: the import writes a total, not a change. If store B had its own stock movements since the export, they are gone.

Method 2 — build it against the Admin API

Both stores expose an Admin API. You subscribe to the inventory_levels/update webhook on the store that owns the number and write the new quantity into the other one with inventorySetQuantities. In outline, that is a weekend.

It is not the outline that costs. It is:

• Matching. Product and variant IDs differ between stores, so you match on SKU — and then you discover the SKUs are not as clean as you assumed. See below; this is where most of the work lives.
• Races. A restock and a sale can land in the same second. If you read a quantity, do arithmetic, and write it back, you will eventually write a number that was already stale. Shopify offers compare-and-set for exactly this reason, and using it properly is the difference between a sync and an oversell generator — what “real-time” has to mean mechanically is its own guide.
• Retries. The Admin API is rate limited and occasionally fails. Every failure needs a retry that is safe to run twice.
• Silence. When it stops working — a token expires, a webhook is dropped — nothing tells you. You find out from a customer.

Worth it if you have unusual rules that no app models. Otherwise you have built a small piece of infrastructure that has to keep working while you run a shop.

Method 3 — an app

Most merchants land here. The apps in this category all do roughly the same core job, and they differ in ways that only become visible after you have committed. What to actually check:

The seven-question version of that table goes deeper, and the comparison of the actual apps in the category carries their public review records.

The part everyone underestimates: SKU matching

Whatever method you choose, something has to decide that this item in store A is that item in store B. Internal IDs cannot do it — they are per-store. So the match runs on SKU, and the quality of your sync is capped by the quality of your SKUs.

Three things go wrong, in rising order of damage:

1. Blank SKUs. Nothing to match on, so the item is simply invisible to the sync. Usually harmless, always confusing.
2. SKUs in one store only. Fine and expected — the stores are not identical. You want these listed, not guessed at.
3. Duplicate SKUs inside one store. The dangerous one. If SHIRT-M appears on two variants in store A, there is no correct answer to which one store B’s SHIRT-M should follow. An app that picks one is going to be wrong roughly half the time, and it will be wrong silently.

Before you connect anything, export your products from both stores and check for duplicate and blank SKUs. It is twenty minutes, and it predicts almost everything about how the sync will behave.

Before you go live, whatever you chose

• Run in preview or dry run against the real catalogue, not a test store. Test stores have clean SKUs; that is exactly what makes them useless here.
• Read the matching report end to end. The number that matters is not how many matched — it is whether the ones that did not match are the ones you expected.
• Change one quantity in the main store and watch it land. Then change one in a store that follows and confirm it is not pushed back, if you chose one-way.
• Decide who owns the number. One-way sync only works if everyone knows which admin to edit stock in. With three or more stores, that decision generalises into the hub-and-spoke operating model.

Where StockUnison sits

StockUnison is the one-way, app-based option, built narrowly: Shopify to Shopify, inventory quantities, one main store into as many connected stores as you like. Matching is by SKU, duplicates are reported and never synced, every connection starts in preview mode, and every write is in a log you can read. It does not create products, and it does not delete anything.

There is a free plan that keeps matching, preview mode and the log, so both catalogues can be matched against each other before anything is paid for.

It is a poor fit if you need two-way sync, if you are syncing to marketplaces rather than Shopify stores, or if you need products and prices copied today rather than quantities — those are on the roadmap, not in the app.