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 diverge quietly and the discovery arrives as an oversell, long before any report shows it.

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, which its marketing page will not tell you.

Simple products sync easily. Problems concentrate in variable products, where each variant needs its own SKU and stock record — a marketplace matches on the identifier, not on your parent product — 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. Amazon's SP-API and eBay's Sell API both answer a burst with a 429 you are expected to respect, 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. Retries need exponential backoff so a rate limit does not become a stampede, and an idempotency key so a retried write does not decrement stock twice. You need an error log somebody actually reads, a heartbeat — the integration writes a timestamp on every successful push, and an alert fires when that timestamp goes stale — and the ability to force a full reconciliation on demand, because drift does not 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, returns restocked within 48 hours, a defined location for damaged stock, and a weekly cycle count on your twenty 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.