A Shopify supplier feed with missing products should not automatically become a list of products to set to zero stock. I built feed-health holds into BC Supply Ops so short or broken files stop removals and reach a review queue. The next decision is just as important: what evidence makes that feed safe to release?
Why I put a hold before inventory removals
In BC Supply Ops for BeautyCorner.gr, I built operations around a 70,000+ product store and 7 suppliers. Three suppliers were automated; four used spreadsheets. Short or broken feeds held removals instead of mass-zeroing inventory, with the issue surfaced for review.
The decision was to separate receiving data from trusting it enough to change a live store. Stock sync produced a reviewable plan before writes. Operators had explicit confirmations, write guards, and recorded sync state.
That is the documented implementation. The acceptance sheet and release procedure below are how I would specify this safeguard for another store; they are not additional claims about that project's internals. For the surrounding import, pricing, and ordering architecture, see my multi-supplier Shopify operations walkthrough.
Does a missing row really mean zero stock?
I would first ask the supplier what the file represents. Is it a complete snapshot, a list of changed products, or an export restricted to one category? Write that agreement beside the importer configuration before enabling any missing-product rule.
A row absent from a changes-only feed tells you nothing about its current quantity. Even with a complete snapshot, I would infer zero only after confirming completeness and agreeing that omission means unavailable. An unexpected export filter should produce a review task, not a new stock policy.
Use separate outcomes for explicit zero, missing, and invalid quantity. I would reject a blank or unreadable value instead of converting it to zero. A valid explicit zero can proceed only after the file and product match pass their checks.
Define the destination quantity as carefully as the source. Shopify's inventory state definitions distinguish sellable Available inventory from On hand, which includes Committed and Unavailable quantities. A supplier's warehouse total needs an agreed mapping before it can become a Shopify quantity.
What should make the importer hold a file?
I would evaluate each supplier separately against its last accepted file with the same scope. Compare unique product identities and successful matches as well as total rows. A plausible row count alone does not prove the intended products are present.
Use this acceptance sheet before authorizing writes. Its rules are a proposed operating checklist, not Shopify settings or universal thresholds.
| Check | Evidence to retain | Hold when |
|---|---|---|
| File identity | Supplier, export time, received time, saved file reference | The file is old, incomplete, or for another supplier |
| Export scope | Snapshot or changes-only agreement; included categories | Scope changed or omission has no agreed meaning |
| Parsing | Expected columns, rejected rows, quantity validation | Required data is missing or quantities cannot be interpreted |
| Matching | Unique identifiers, matched variants, unresolved duplicates | Matches collapse or an identifier points to ambiguous variants |
| Proposed changes | Explicit zeros separated from absence-based zeros | Removals are unexplained or exceed the supplier's review limit |
| Write ownership | Intended variants, locations, and inventory state | The plan would touch quantities this importer does not own |
Set review limits from accepted supplier history and the merchant's tolerance for incorrect availability. I would not copy a percentage from another importer and call it safe. For a new supplier without history, start with manual acceptance and collect the evidence needed to set limits.
Choose the hold's scope explicitly. If file identity or parsing is unreliable, I would block every inventory write from that file. If only omission-based removals are doubtful, separately validated rows might proceed under an agreed policy; do not let that exception become automatic.
How long can you keep the previous stock values?
A hold prevents an untrusted file from changing quantities; it does not prove the previous quantities are still accurate. I would track the age of the last accepted supplier snapshot separately from the time of the latest attempted download. Repeated failed downloads must not make the data appear fresh.
Assign a named reviewer and a deadline based on that supplier's expected delivery schedule. Record which products remain exposed to uncertain availability. A hold with no owner or next review time can quietly become permanent.
Agree in advance what happens when accepted data becomes too old. Options might include obtaining a verified replacement feed or restricting affected products through the merchant's approved availability process. Keep that decision separate from interpreting a broken file as proof that everything sold out.
For products available from several suppliers, I would review the affected source before changing the shared listing. Do not remove independently verified availability simply because another supplier's feed failed. The ownership check in the acceptance sheet makes that boundary reviewable.
What evidence should release the hold?
I would require a corrected file or a documented explanation that resolves the exact hold reason. If the supplier intentionally removed a category, record that scope change. If identifiers changed, review the mapping before rebuilding the plan.
Tie approval to the specific accepted file and proposed changes. Replacing the file or changing the mapping should invalidate the earlier approval. Keep rejected files for diagnosis, but do not promote them into the baseline used to judge tomorrow's feed.
Before writing, refresh Shopify quantities and rebuild any stale part of the plan. For API integrations, Shopify's inventorySetQuantities reference reserves absolute quantity setting for a system acting as the inventory source of truth. It recommends the compareQuantity check to guard against concurrent changes.
I would treat a failed comparison as a reason to read and reconcile again, not permission to disable the check. A current Shopify comparison also cannot establish whether an old supplier snapshot is trustworthy. Both the source data and the destination plan must still pass review.
Use these acceptance checks before enabling routine releases:
- A truncated snapshot stays held and does not replace the accepted baseline.
- A changes-only file leaves absent products untouched.
- An ambiguous identifier cannot authorize a variant update.
- A replacement file requires its own reviewed plan.
- A quantity changed after review triggers reconciliation before an absolute write.
- An expired hold remains visible until its availability decision is recorded.
These are tests I recommend running with saved fixtures and writes disabled. They are not reported test results from BC Supply Ops.
What if the bad feed already zeroed products?
Pause the affected importer before making corrections, so another run cannot immediately repeat the change. Save the suspect file, its mapping, and the generated plan. Establish the affected supplier and locations before deciding how broadly to intervene.
Inspect representative variants using Shopify's inventory adjustment history. It shows the adjustment date, activity, creator, and resulting inventory quantities. Use that evidence alongside the importer's own records to determine which changes need investigation.
I would not replay an old export as a blanket rollback. Reconcile verified supplier availability with the store's current quantities and intervening activity, then produce a fresh correction plan. Apply a reviewed batch and inspect the result before expanding it.
Keep confirmed corrections, unresolved products, and held changes separate in the report. Completion should mean the intended corrections were checked, not merely that the importer finished running.
Where to start
Choose one supplier and compare its latest file with the last accepted snapshot. Fill in the acceptance sheet, then ask the importer to produce a plan with explicit zeros and missing-product removals counted separately. Resolve any uncertainty about export scope before enabling absence-based updates.
Keep stock review alongside the holding queue for products missing images: each queue needs a clear reason and release decision. If your current sync cannot explain its proposed removals, book a call and bring a sanitized feed, its mapping, and a sample change report. Those give us a concrete starting point for placing the hold before the next live update.