How to sync orders and inventory across your shop and marketplaces

If you sell in more than one place — your own storefront plus a marketplace or two — then somewhere on your to-do list is a quiet, recurring chore: keep the stock numbers honest and make sure no order falls through a crack. That chore is what people mean when they say they need to sync orders and inventory across channels. It sounds simple. It is not, and the gap between how simple it sounds and how it actually behaves is where a lot of avoidable pain lives.

This is a plain-English guide to that gap. We’ll cover what syncing actually means (it’s really two jobs, not one), why overselling happens even to careful sellers, the difference between real-time and scheduled sync and why it matters more than the marketing suggests, and the parts nobody puts in the sales deck — identifier mapping, partial failures, returns. By the end you’ll have a clear mental model of what good multichannel sync looks like, whatever tool you eventually use to do it.

Syncing is two jobs, not one

The first thing to get straight: “sync orders and inventory” bundles two different flows that move in opposite directions.

Inventory sync flows outward. Your stock lives in one place — your shop, a warehouse, an ERP — and that number needs to be reflected everywhere you sell. Sell one unit anywhere, and every channel’s available quantity should drop by one. This is the job people usually mean by multichannel inventory sync, and its entire purpose is to stop two channels from selling the same last unit.

Order sync flows inward. Orders are created out at the edges — on each marketplace, on your storefront — and they need to be pulled back into one place where you actually fulfill them. This is marketplace order management: collecting every order from every channel into a single queue, tracking each one through its lifecycle, and pushing fulfillment status (shipped, tracking number) back out to the channel it came from.

Almost everything that goes wrong with multichannel selling is a failure of one of these two flows: stock that didn’t flow outward fast enough (overselling), or an order that didn’t flow inward reliably (a missed or duplicated order). Keep the two directions separate in your head and the whole problem gets easier to reason about.

Inventory sync: the war against overselling

Let’s take the outward flow first, because it’s the one that bites soonest.

On a single channel you never think about stock sync — the channel knows what it has and decrements as it sells. The moment you add a second channel, you’ve created a coordination problem. Channel A and Channel B each believe they own the inventory. Nothing tells Channel B that Channel A just sold the last unit. A customer buys it on B anyway. Now you owe someone a product you can’t ship, and you’re writing the apology email.

Multichannel inventory management is the discipline of having one authoritative stock number — a single source of truth — and propagating every change to it out to all connected channels fast enough that this race never happens. “Fast enough” is doing a lot of work in that sentence, and it’s the whole ballgame.

The mechanics, stripped down, are:

• One source of truth. Stock is owned by exactly one system. Every other channel is a downstream copy that gets corrected, never the place where the real number lives.
• Change detection. Something has to notice the instant stock moves — a sale, a return, a restock, a manual edit.
• Propagation. That change is pushed out to every channel, ideally before another channel can sell the same unit.

The failure mode is always the same: a window of time where one channel’s number is stale. Close the window and you don’t oversell. Leave it open and you will, eventually, in proportion to how busy you are.

Why overselling happens: the staleness window

Here’s the part worth internalizing, because it explains both why overselling happens and how the better tools avoid it.

Overselling is almost never caused by a bug in the subtraction. It’s caused by stale data — a channel making a sale based on a stock number that was already wrong. And the size of your overselling risk is, almost exactly, the size of your sync window.

Suppose your system updates each channel by checking stock every fifteen minutes. That’s a fifteen-minute window in which any channel can sell a unit that another channel already sold. On a slow day you might never notice. During a promotion, a feature placement, or a seasonal rush, fifteen minutes is enough time to sell the same last unit on three channels at once. The faster you sell, the more the window costs you — which means the problem shows up exactly when business is good and you can least afford it.

This is why the timing of your sync isn’t a technical footnote. It’s the single variable that most determines whether you oversell. Everything else — nice dashboards, bulk editing, pretty reports — is secondary to how small that window is.

Real-time vs scheduled sync

There are two broad ways to close (or fail to close) the staleness window, and the difference between them is the most important architectural choice in this whole space.

Scheduled (polling) sync. The system wakes up on a timer — every fifteen minutes, every hour, a few times a day — asks each channel “what’s changed?”, and reconciles. It’s simple to build and simple to reason about. Its weakness is structural: the window can never be smaller than the interval. A fifteen-minute poll means a fifteen-minute worst case, every time, forever. For low-volume sellers, or for slow-moving stock, that can be perfectly fine — don’t let anyone shame you into complexity you don’t need.

Real-time (event-driven) sync. Instead of asking on a timer, the system reacts to events as they happen. A sale fires an event; the event immediately triggers propagation to every other channel. There’s no fixed window — the system responds in roughly the time it takes a message to travel, not in the time until the next scheduled check. This is what people mean by “real-time” inventory sync, and for high-volume or promotion-driven selling it’s effectively the baseline expectation now, because it’s the only approach where a flash sale doesn’t turn into a pile of overselling incidents.

The honest nuance: event-driven is more work to build correctly, because reacting to a flood of individual events forces you to handle ordering, duplicates, and failures explicitly rather than papering over them with a periodic full reconciliation. Many robust systems do both — event-driven propagation for speed, plus a slower scheduled reconciliation as a safety net to catch anything the events missed. If you’re evaluating a tool, “is your inventory sync event-driven or polled, and what’s the worst-case delay?” is the single most revealing question you can ask.

Order sync: one queue, every channel

Now the inward flow. Orders arrive at the edges and have to come home.

Marketplace order management is the job of pulling every order from every channel into one place, tracking it through its whole order lifecycle — captured, paid, allocated against stock, picked, packed, shipped, sometimes returned — and pushing the relevant status back out so the marketplace (and the customer) knows what’s happening. The value, again, is in the word one: one queue your team works from, instead of three browser tabs and a prayer.

Done well, order ingestion has a property that’s easy to overlook until you lose it: nothing gets dropped, and nothing gets pulled twice. That sounds obvious. It’s surprisingly hard, and it’s where a lot of homegrown integrations quietly fail.

The hard parts nobody puts in the deck

If syncing were just “subtract one and copy the order,” every tool would work and this article wouldn’t exist. Here’s what actually makes it difficult — the things we’ve learned to check any solution against.

Identifier mapping. Your shop calls a product SKU-4471. eBay has its own offer ID for it. Your warehouse has a third code. Every order line and every stock update has to be translated between these identifier systems, in both directions, without ever crossing two products. Get the mapping subtly wrong and you’ll decrement the wrong item’s stock — a failure that’s maddening to debug because nothing errors; the numbers just drift.

Idempotency and deduplication. Networks fail mid-request. A channel says “here’s an order,” your system saves it, and the acknowledgment gets lost on the way back — so the channel sends it again. If your ingestion isn’t idempotent (able to receive the same order twice and store it once), you’ll fulfill duplicates. The fix is designing every operation so that doing it twice is the same as doing it once.

Partial failures and resumability. You’re halfway through importing two hundred orders and the connection drops, or the marketplace rate-limits you. What happens? A fragile integration loses its place and either re-imports everything (duplicates) or skips ahead (drops). A robust one keeps a cursor — a durable watermark marking exactly how far it got — so it can resume from the precise point it stopped. “Nothing’s lost if anything pauses” is a property you have to design for; it doesn’t come free.

Returns and cancellations. Stock doesn’t only flow one way. A return puts a unit back; a cancellation releases an allocation. If your sync only handles sales, your numbers will slowly drift too high, and you’ll find out via a stockout on something your system swears is in stock.

Rate limits and API drift. Every marketplace throttles you, and every marketplace changes its API on its own schedule with no regard for your roadmap. A sync that works today has to keep working through a listing-flow change next quarter — which is why real integration tests against the actual platforms, not mocks, are the difference between a tool that survives and one that breaks silently.

None of these are exotic edge cases. They’re the normal weather of multichannel selling. The reason “just write a script” so often ends in tears is that the script handles the happy path and none of this.

Your three options for actually doing it

So how do you get this done? Practically, there are three paths.

Pay a SaaS channel manager. The fastest start: sign up, connect your channels, and someone else owns the plumbing. The trade is that many of them charge per order — a fee that grows precisely as you do — and your order history, customers, and pricing logic live on their infrastructure under their policies. You configure what they anticipated; the wrinkle specific to your business is yours to work around, not change.

Write and maintain your own scripts. Maximum control, and it can be the right call for a simple setup. But you’ve just signed up to handle every hard part above — mapping, idempotency, resumability, returns, rate limits, API drift — and to keep handling them forever, alone, as a private codebase nobody else maintains. The happy path is a weekend; the long tail is a second job.

Own the engine — self-hosted and open source. A third path that’s grown up in the last few years: run an open-source orchestration layer on infrastructure you control. No per-order meter, your data stays with you, and because the code is open you can change behavior instead of working around it. The trade, honestly, is that you host it — someone runs the box and keeps it updated. For an agency, that’s billable work a client used to hand a SaaS vendor anyway; for an in-house team, it’s the weight of any other self-hosted service you already run. Not free. But owned outright, instead of rented unboundedly.

There’s no universally right answer here — it depends on your volume, your team, and how much owning the foundation is worth to you. What matters is going in with eyes open about which trade you’re making.

Where we come into this

We’ll be upfront, because the principle we write by is to never oversell: this whole article is the problem OpenLinker exists to solve, and OpenLinker is something we’re still building.

OpenLinker is the open-source engine for e-commerce orchestration — self-hosted, Apache 2.0, no per-order tax. The whole design starts from the hard parts above: ingestion that’s webhook-triggered where a platform can push events and cursor-polled where it can’t — both converging on one idempotent path, so duplicate deliveries can’t double-ingest and nothing’s lost if anything pauses; identifier mapping off a single unified seed, so the wrong product never gets decremented; and a plugin architecture so the long tail of marketplaces, carriers, and invoicing providers gets built as adapters against a stable core rather than bolted on. It’s the “own the engine” option, built deliberately from the architecture up.

We’re building it in the open, and we keep our integrations honest and public — what’s working, what’s in progress, what’s only planned — precisely so nobody confuses a goal with a guarantee. If the way of thinking in this article is the way you think about your channels, we’d love to have you along early:

• Star and watch the repo on GitHub — the clearest signal that an open-source orchestration engine is worth building.
• Subscribe to the newsletter — a monthly note on what shipped, what’s in progress, what got cut. No noise.
• Talk to us as a design partner — if you’re an agency building multichannel work for clients, we’re working closely with the first few and there’s room for more.

Syncing orders and inventory well is mostly about respecting how it really breaks. Whatever you build or buy, hold it to the standard above — and if you’d rather own that engine than rent it, come build the rest of it with us.