Keeping Store, Marketplace and POS Inventory in Sync

Overselling happens when two sales channels each believe they hold the last unit. A web store, a marketplace listing and a shop till all sell from the same shelf, and inventory sync is the plumbing that keeps their numbers honest. When it is designed loosely, you find out through cancelled orders and apology emails.

Five decisions do most of the work: which system owns the count, how changes travel, how you cover the gaps that remain, what sits in the middle, and how you check that it is all still working. They are covered here in that order.

One system owns the stock number

Pick a system of record and write it down. It should be the place where goods are received and counted. For a larger retailer that is an ERP or an inventory management system. For a shop with a stockroom it is often the POS. For a small online seller it can be the web store itself.

Then hold to one rule: only the owner sets absolute quantities. Every other channel reports events (a sale, a cancellation, a return) and receives the resulting available quantity. If the marketplace connector and the POS each write "quantity is 7" from their own point of view, the last write wins and the count drifts a little further every day.

None of this works without clean identifiers. Each sellable unit needs one SKU that is identical in every system, and every variant needs its own. Where a marketplace insists on its own identifier, keep a mapping table. Bundles and kits should map to their component SKUs, so that selling a set reduces each part. Before any integration work, export the SKU list from every channel and compare them. The mismatches are the first job.

How changes travel between systems

Method	How it works	Typical delay	Fits when
Event push (webhooks)	The channel notifies the hub as each sale happens	Seconds	Low quantities, fast sellers, several channels
Polling	The hub asks each channel for changes every few minutes	Minutes	Channels whose APIs offer no events
Scheduled batch file	A full stock file is exchanged on a timetable	Hours	Deep stock, slow sellers, older ERP systems

Most setups that hold up use two of these together: events for sales as they happen, and a scheduled full comparison that corrects whatever drifted.

On WooCommerce, events come from webhooks, configured under WooCommerce > Settings > Advanced > Webhooks, with topics for new orders and product updates. WooCommerce disables a webhook after repeated failed deliveries, so the receiving end needs monitoring. The webhooks documentation has the details. Stock is written back through the REST API:

curl -X PUT https://example.com/wp-json/wc/v3/products/794 \
  -u consumer_key:consumer_secret \
  -H "Content-Type: application/json" \
  -d '{"manage_stock": true, "stock_quantity": 12}'

Variations have their own endpoint under the parent product. That call sets an absolute number, which is correct only when the caller is the system of record.

Where overselling really comes from

When we trace an oversold order, the cause is usually one of these:

• The sync interval. A fifteen-minute batch is fifteen minutes in which two channels can sell the same unit.
• The channel's own delay. A marketplace may take time to apply an update after it has accepted it.
• Peaks. Rate limits and queues back up during a promotion, which is when stock moves fastest.
• A failed message nobody retried. One lost event leaves the count wrong until the next full comparison.
• Unpaid orders. Decide whether an order awaiting payment reserves stock. In WooCommerce the "Hold stock (minutes)" setting under WooCommerce > Settings > Products > Inventory reserves it for that long, then cancels the pending order and releases the stock. Other channels need to hear about both the reservation and the release. The product settings documentation describes the option.
• A till working offline. A POS that loses its connection keeps selling from its last known count and reports later.
• Returns counted twice. Once when the channel cancels the order and again when the warehouse books the goods in.
• Manual edits. Someone corrects a number in a channel's admin, and the next sync overwrites it or spreads it.

Half of this list is about timing. The other half is about process. Faster sync only fixes the first half.

Safety stock buys the time the sync cannot

No architecture makes every channel agree at every instant, so publish less than you hold:

available to sell = on hand - reserved - safety buffer

A single buffer for the whole catalog is the lazy version, and it hides stock you could have sold. Set it by channel and by product:

• larger for channels that update slowly and for products that sell quickly,
• larger where a cancellation costs more, since marketplaces track cancellations against the seller account,
• zero for items you hold a single unit of, which should then be listed on one channel only.

For a marketplace promotion, set aside a fixed quantity for that channel instead of letting it draw on the shared pool. Each time an oversell does happen, record the cause and adjust the buffer or the process. After a few months the buffers reflect your own data, not a guess.

Connector, middleware or ERP

Two endpoints, such as a store and a POS or a store and one marketplace, are usually served well by a direct connector or plugin. Ask four things about it: whether it sends changes or absolute values, how often it runs, how it handles variations and bundles, and what it does when a request fails.

Three or more and direct connections stop scaling. Each pair needs its own link, and each link has its own idea of the truth. Put a hub in the middle: an inventory or order management system, an ERP with channel connectors, or middleware you own.

Whatever the hub is, it has the same duties. It receives events from every channel, applies them to the master count and pushes the result to all the others. To do that reliably it needs:

• Idempotency. The same order event delivered twice must reduce stock once. Key every change on the order and line identifiers.
• A queue with retries that back off, and a list of permanently failed messages that a person reviews.
• Respect for rate limits, so a peak slows the queue instead of getting the integration blocked.
• Logs that operations staff can read without a developer.

Custom middleware earns its cost when an older ERP has no connector, or when your rules are unusual: made-to-order items, routing between warehouses, kits assembled on demand. We go through the integration patterns in integrating an ERP with your online store, and the failure handling in designing integrations that survive API failures.

Checks that show the inventory sync is healthy

1. A daily reconciliation report comparing the master count with each channel, SKU by SKU. The list of differences should be short and getting shorter.
2. Queue age and failed-job alerts. If the oldest unprocessed event is more than a few minutes old, someone should be told.
3. A weekly count of oversold orders, each with its cause.
4. The last-unit test. Sell the last unit of a test SKU on one channel and time how long the others take to show zero. Repeat it before every peak season.
5. Cycle counts that feed the system of record and nothing else.

What to set up yourself and what to hand over

Choosing the system of record, cleaning up SKUs, setting buffers and configuring an off-the-shelf connector are operational decisions your own team should own. A hub that talks to an ERP, a POS and two marketplaces is software, with queues, retries and monitoring to design. That is API development and integration work, and when the stock system itself needs replacing it becomes a CRM and ERP project. We scope both for retailers as part of our eCommerce and retail work.

Frequently asked questions

Can inventory be synced in real time across every channel?

You can get close, but not to zero delay. Your side can react to a sale within seconds, while each external channel applies updates on its own schedule. Design for a gap of seconds to minutes and cover it with a safety buffer.

Should the POS or the online store be the source of truth?

Whichever system is used to receive and count stock. In a shop-led business that is often the POS. Once there is a warehouse or more than two channels, it is usually better to move ownership to an inventory system or ERP and treat both the till and the web store as channels.

How do bundles and kits affect stock sync?

A bundle has no stock of its own. Its availability is whatever the scarcest component allows, and selling one reduces every component. The hub has to calculate that number and send it to each channel where the bundle is listed.

Does WooCommerce sync stock with marketplaces by itself?

No. WooCommerce manages its own stock levels and provides webhooks and a REST API for other systems to use. Keeping a marketplace or a POS in step needs an extension, a connector service or a custom integration built on those interfaces.