One stock number, several places selling it

Exactly one system holds the authoritative stock figure and everything else receives it. Which one depends on where your operations actually run: WooCommerce is a reasonable master for store-led businesses, a warehouse or ERP system for operations-led ones, and a dedicated inventory platform when marketplaces dominate. What never works is two systems both writing stock, because they will diverge quietly and you will discover it through an oversell rather than a report.

• One master, everything else read-only for stock
• Store-led business: WooCommerce can be the master
• Operations-led: warehouse or ERP holds the number
• Marketplace-heavy: a dedicated inventory platform

No sync is instant. Between a sale on one channel and the stock update on another there is a window — sometimes seconds, sometimes minutes — and in that window two customers can buy the last unit. A buffer holds back a small amount of stock from external channels to absorb that gap. The right size depends on how fast the item sells and how bad an oversell is on that channel: a marketplace where oversells damage your seller metrics deserves a larger buffer than your own store, where you can apologise directly.

"Available" is ambiguous, and the ambiguity causes real problems. Is stock in someone's cart available? WooCommerce holds it only briefly during checkout. Is stock allocated to an unfulfilled order available? Definitely not, though some integrations count it. Is stock physically present but damaged available? Only if someone marked it. Write down your definition, make sure every connected system uses the same one, and check what your integration actually does rather than what its marketing page implies.

Simple products sync easily. Problems concentrate in variable products where each variant needs its own stock record and mapping to a marketplace listing, and in bundles or kits where selling one unit must decrement several components. If a bundle is not modelled correctly, its components stay available on other channels and you oversell twice. Any integration you evaluate should be tested against your most complicated product, not your simplest one — the simple case always works in a demo.

Assume it will. APIs rate-limit, marketplaces have outages, and a bad update can propagate a wrong number everywhere in seconds. What matters is that failures are visible, retried and reversible. You need an error log somebody actually reads, alerting when a channel has not updated within an expected window, and the ability to force a full reconciliation on demand rather than waiting for drift to correct itself. A nightly full sync alongside real-time deltas is a common and sensible belt-and-braces arrangement.

No integration fixes a stockroom where counts are wrong. If receiving is inconsistent, returns are restocked late, damaged goods stay in the count and nobody cycle-counts, then you are synchronising a fiction faster. Sort the physical process first: consistent receiving, prompt restocking of returns, a defined location for damaged stock, and regular cycle counts on your fastest movers. That is usually where the real oversell rate lives, and it costs nothing but discipline.

One sales channel and a small catalogue does not need an inventory platform — WooCommerce's own stock handling is adequate and the added complexity buys nothing. Consider a proper solution when you add a second selling channel, when oversells start happening monthly, or when a marketplace begins penalising your account for cancellations. Before that, a subscription and an integration to maintain is a cost with no matching problem.