The same SKU listed on ten marketplaces will oversell the moment two of them sell the last unit before the others hear about it. Here's the small set of rules that keeps stock counts honest across channels.
By Team WebSync · · 4 min read

We've built and maintained the sync layer between a single inventory source and dozens of marketplaces and web shops. The feature that breaks first, every time, isn't listing products or pulling orders - it's keeping the stock number the same everywhere when several channels are selling the same unit at once.
You have one physical quantity for a SKU, and it's listed on, say, ten channels. Channel A sells the last unit. Now you need to push "0" to the other nine. That push takes seconds to minutes - an API call per channel, subject to that channel's rate limits, queued behind everything else you're syncing. In that window, Channel B can sell the same unit. You're now oversold, and every oversold order is a cancellation, a refund, and a metric the marketplace holds against your account.
There is exactly one authoritative quantity per SKU, and it lives in your system, not in any channel. Channels are downstream copies. An order from any channel decrements the source; the source then fans the new number out to every channel. If a warehouse tool, a spreadsheet import, and three marketplaces can all write stock directly, you have five sources of truth and no way to reconcile them.
Don't list your full quantity. Keep a small buffer unlisted - a fixed number for low-stock items, a percentage for fast movers. It absorbs the sync lag: the buffer sells instead of the count going negative, and you top the listed number back up on the next push. It costs you a little visible availability in exchange for far fewer cancellations.
Stock updates arrive out of order under retries and parallel workers. Attach a monotonic version or timestamp to each change, and have the channel-push layer refuse to apply one older than what it last sent. Without this, a delayed "quantity 5" can land after "quantity 0" and re-open a sold-out listing.
However careful the real-time path is, a missed webhook or a failed push will eventually leave a channel showing the wrong number. Run a full sweep - every SKU, every channel, source value against listed value - on a schedule: hourly for a busy catalogue, nightly for a slow one. Log every correction. A rising correction count is your early warning that something in the real-time path is broken.
Everything above assumes each channel's listing is correctly mapped to one internal SKU. Mismatched or duplicated mappings are the other large source of stock errors. Validate the mapping when a listing is connected - consistent SKU format, a matching barcode (GTIN, EAN, or UPC) where one exists - not months later when the numbers don't add up.
The Product CSV Validator flags duplicate SKUs and bad barcodes in an export before you import it; the SKU Generator keeps new codes in one consistent pattern; and the GTIN Converter checks and normalises barcodes across formats.
The real-time sync gets the credit, but it's the scheduled reconciliation sweep that catches the errors nobody noticed.
Keep one authoritative stock quantity in your own system, decrement it on every channel's orders, and fan the new number out to all channels. Hold back a small unlisted buffer to absorb sync lag, push decreases and zero-outs ahead of routine changes, version updates so stale ones can't apply, and run a scheduled sweep to correct drift.
Generate consistent SKU codes in bulk from a custom pattern with variant permutations, sequential numbering and collision checking.
Check a product CSV for missing columns, broken variant handles, duplicate SKUs, invalid barcodes and bad prices before you import it.
Convert product codes between GTIN-8, GTIN-12 (UPC-A), GTIN-13 (EAN-13) and GTIN-14, validate check digits, and normalise a whole catalog in bulk.
Turn a CSV or TSV table into JSON records, or flatten JSON back into a spreadsheet-ready table.
Book a free consult - we'll scope it and give you a fixed price.