How E-commerce Inventory Synchronisation Works

Inventory synchronisation is not “copy the number from the warehouse into the website.” Each channel has a different idea of available: physical count, reserved for an unpaid cart, allocated to a marketplace order that has not shipped, and damaged stock that must not sell. If you push the same integer everywhere, you will oversell during a promotion and spend the next week on refunds.

This article explains the operational model Palmate uses for e-commerce development and API integration: a stock authority, a reservation layer, outbound adapters, and observability. A worked architecture — WooCommerce, a warehouse system, and a marketplace — is in the sample multi-channel inventory synchronisation study. It is labelled as a sample; it does not invent a client or a percentage improvement.

Why channels disagree

A warehouse receipt says 100 units arrived. The website might still show 80 because 20 are in unpaid checkouts. A marketplace might show 100 because its feed is twelve minutes old. Finance might show 95 because five units were written off and nobody told the feed.

Those are not “bugs in the plugin.” They are different quantities:

• On-hand — physically in a location, after receipts and adjustments.
• Reserved — promised to a cart, order, or marketplace acknowledgement, not yet shipped.
• Available to sell / available to promise — on-hand minus reservations minus safety stock, sometimes minus inbound that you refuse to sell early.
• In transit / allocated — leaving or sitting in a 3PL that the storefront should not treat as sellable on the origin warehouse.

A naive two-way sync treats all of these as one field named qty. Then a webhook retry decrements twice, a marketplace rate limit replays an old quantity, and a pack of six units is sold as six separate SKUs.

Pick an authority

One system owns on-hand for a location. Often that is the warehouse or ERP. The website should not be allowed to “fix” on-hand in admin during a sale unless that write goes through the same service and audit trail as a warehouse adjustment.

Storefronts and marketplaces are clients. They receive available-to-sell figures. They send order and cancellation events. They do not win an argument with a cycle count.

If you cannot name the authority in one sentence, stop coding. Map SKUs and packs first: BOX-6 might be one sellable SKU and six base units. The sample architecture lists this as the first implementation step for a reason.

Reservations, not hope

When checkout starts — or when a marketplace order is acknowledged — hold a reservation with an expiry. Payment failure and abandoned carts release it. Shipment converts reservation into a decrement of on-hand (or the warehouse already decremented on pick; the service must not decrement twice).

Without reservations, two channels can sell the last unit in the same minute. With reservations but without idempotency, a duplicate webhook sells it twice on paper.

Idempotency keys on inbound order events are mandatory. Vendors retry. Your job is to treat “order X already applied” as success, not as another minus-one.

Direction of updates

Outbound workers push availability to each channel on that channel’s terms: WooCommerce REST batch updates, marketplace feed or API, rate limits, and a stored last-successful timestamp. Inbound is events: orders, refunds, cancellations, and warehouse receipts.

Bidirectional “whoever wrote last wins” is how you resurrect old quantities. If the marketplace rejects an update, do not silently skip it; dead-letter the message and show lag on an operator screen.

How API integration automates operations covers webhooks versus polling. Common mistakes with third-party APIs covers retries, pagination, and auth expiry — all of which show up in inventory projects as “stock was fine until the token died at 2am.”

Discovery still looks like spreadsheets

Before APIs, someone will email a CSV of SKUs. Use it. The JSON to CSV converter turns sample API payloads into tables so operations can confirm that sku, location, and qty mean what engineering thinks they mean. Nested variants often flatten into dotted keys (parent.sku, pack.size); if a nested array becomes a JSON string in one cell, you do not yet have a rectangular catalogue — you have a modelling problem.

Keep that mapping in version control, not in a slide. Packs, kits, and marketplace-only SKUs belong there.

A minimal event flow

receipt/adjustment → inventory service (on-hand)
checkout/marketplace ack → reservation
payment fail / timeout → release
order confirmed → consume reservation
refund/cancel → restock policy (restock vs write-off)
outbound workers → website & marketplace available qty

Partial failure is normal. The marketplace may accept 90% of SKUs and reject the rest for mapping errors. Operators replay after fixing the map; they do not “run the spreadsheet again” against live channels.

What “in sync” should mean

Success is not “all numbers equal.” Success is:

• One explainable on-hand per SKU per location.
• Available-to-sell that never exceeds what you are willing to ship.
• Measurable lag (seconds or minutes, not “usually fine”).
• A person who can explain a mismatch without opening three admin panels.

The sample inventory sync architecture adds a queue lag gauge and a dead-letter table for that reason. Oversells during promotions are the business symptom; poisoned messages and rate limits are the technical ones.

Estimating the work

This is an integration project with a domain model, not a plugin toggle. Auth, webhooks, a datastore for reservations, and channel adapters all add surface area. Use the API project estimator to sanity-check endpoint count, webhook needs, and traffic — then add catalogue mapping and a staging replay of a week of historical orders before you turn on a marketplace feed.

WooCommerce-specific checkout and catalogue work still sits under e-commerce development. The sync service is often a small Node.js (or similar) app with PostgreSQL and Redis for short-lived holds, as in the sample stack. Docker Compose is enough for many VPS deployments; it does not replace the domain rules.

What not to do

• Do not let the website write on-hand except through the inventory API.
• Do not two-way sync “quantity” without reservations and idempotency.
• Do not treat marketplace available as warehouse truth.
• Do not skip a staging test against real historical orders.
• Do not invent a 40% oversell reduction in a case study. Measure your own incident rate.

Inventory sync is operations expressed through APIs. Get the quantities named, the authority named, and the failures visible — then the storefront and the warehouse can share a number that staff will actually trust.