Marketplace integration

Keeping stock in sync across a dozen sales channels without overselling

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

Title 'Multi-Channel Inventory Synchronization' above a diagram of a central inventory hub pushing one matching stock count out to several e-commerce marketplace channels, with a 'zero overselling' shield

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.

Why overselling happens

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.

Overselling is a timing problem, not a data problem. The stock number is correct; it just hasn't arrived everywhere yet.

One source of truth, and nothing writes around it

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.

Hold back a buffer

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.

Push low numbers first, and prioritise the risky ones

  • When stock drops, the update that prevents an oversell is more urgent than one that just changes 40 to 38 - queue decreases ahead of increases.
  • An item at quantity one or two across many channels is the real risk. Push those immediately and individually; batch the high-stock changes.
  • Set a channel to zero the instant the source hits zero - don't wait for the next batch.

Version every update so stale ones can't win

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.

Reconcile on a schedule, because sync will drift

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.

Match the SKUs before any of this matters

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.

How do you stop overselling when the same product is listed on multiple marketplaces?

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.

Share this guideLinkedInXWhatsAppFacebook
All guides

Want this built for you?

Book a free consult - we'll scope it and give you a fixed price.