Shopify inventory and stock synchronization
Stock is the one entity where Bizmitra is the owner and Shopify is the copy. That makes the direction one-way by design. This guide explains how a quantity finds the right item at the right location, and the one case where Bizmitra deliberately refuses to act.
Last reviewed against the implementation on
At a glance
- Direction
- Bizmitra → Shopify only
- Not imported
- Store stock changes do not flow back
- Needs
- A Shopify inventory item and a location
- Untracked variants
- Reported, never silently changed
Why it is one-way
Stock moves from Bizmitra to Shopify, and not back. Bizmitra holds the position across every warehouse and branch you run; your Shopify store holds one location's sellable quantity. The bigger, more complete number is the one that should win, so it is the one that travels.
A common misreading
Shopify can notify Bizmitra when a storefront stock level changes, and that notification type is listed in the app's manifest. But there is no handler for it — those notifications are not acted on. Adjusting stock in Shopify admin does not update Bizmitra. Make the adjustment in Bizmitra and let it flow outward.
Finding the inventory item
Shopify does not set stock against a product. It sets stock against an inventory item at a location — two ids that Bizmitra has no reason to know on its own. Most of the work in a stock push is finding them.
The inventory item id is resolved in this order:
Resolving the inventory item
Captured automatically when a product was exported to the store. This is the normal case and costs nothing.
If an earlier export already worked it out, it was stored.
By Shopify product id when the mapping has one, otherwise by looking up the SKU. The result is written back into the mapping.
That third step matters for older connections. Products mapped before the import started recording provider details carry no inventory item id, so the first stock push for each one costs a lookup — and then never again, because the answer is stored. It heals itself rather than failing.
Finding the location
The location is resolved from the first of these that answers: a location named on the request, an application-wide setting, a location already chosen for this connection, or — failing all of those — worked out from the store itself and cached on the connection so a bulk export costs one lookup rather than one per product.
Working it out from the store asks about the item's existing stock levels first, because that endpoint is covered by the inventory access the app already requests. Only if that yields nothing does it fall back to listing the store's locations — and that fallback needs an additional permission which is deliberately not in the app's default set.
Why that permission is left out
Adding it to the app would force every existing merchant to re-authorise. For a fallback that rarely fires, that is a bad trade — so on most stores the fallback simply returns nothing and the primary path does the work. If you have picked a location in settings, none of this runs at all.
Untracked variants
This is the one case where Bizmitra deliberately refuses to act, and it is worth understanding because the refusal is the correct behaviour.
If a variant has Track quantity switched off in Shopify, the store will not accept a stock level for it. Bizmitra could turn tracking on and retry — but turning tracking on changes how your storefront behaves: Shopify starts decrementing the quantity and can stop selling the item once it reaches zero.
A merchant may have left something untracked entirely on purpose — made-to-order goods, digital products, services. Silently flipping that switch could stop those items selling. So the default is to stop and tell you which product is affected and what to change, rather than to fix it quietly.
What you will see
A message naming the SKU, saying that inventory tracking is turned off for that product in Shopify and that Shopify will not accept a stock level for an untracked item. Turn on "Track quantity" for it in Shopify, then re-queue the job.
There is an opt-in setting that enables tracking automatically and retries. It is off by default, for the reason above.
When stock changes in Bizmitra
Worth stating plainly, because it determines what number gets pushed:
| Event | Effect on Bizmitra stock |
|---|---|
| Shopify order arrives | None — a sales order does not move stock. |
| Invoice raised from that order | Stock out, one movement per line. |
| Receipt posted | None — this is money, not goods. |
| Refund with returned items | Stock back in, one movement per returned line. |
| Refund without returned items | None at all. |
So if your connection is set to invoice manually, unconverted orders have not reduced stock yet — and the quantity pushed to Shopify will reflect that. See when stock actually moves and the restock rule.
Limitations worth knowing
- One Shopify location. Stock is pushed to a single resolved location. Bizmitra's multi-warehouse position is consolidated into that one number rather than split across several Shopify locations.
- A product with no SKU and no mapping cannot be stocked. There is nothing to identify it by. The error names the Bizmitra product id and the Shopify product id where known, so you can find the row.
- Deleted store products surface here first. If a product was removed from Shopify, no inventory item can be resolved and the push reports it. Re-importing products rebuilds the mapping.