Most of us have wired up at least one commerce API. If you have ever had to keep two of them agreeing about the same row of stock, this one is for you.
Multichannel selling looks like a business decision from the outside. From the code side it is a distributed systems problem wearing a retail costume, and the failure modes are the familiar ones.
One Unit Of Stock, Two Systems That Both Think They Own It
The first real problem shows up the moment the same SKU is listed on your own store and on a marketplace. Two buyers can reach the last unit within the same second, and both platforms will happily accept the order because neither one is the authority.
The fix is boring and non negotiable: pick a single source of truth for available quantity, and treat every channel listing as a projection of it. Push updates outward, never let a channel write back an absolute quantity. Reserved buffers on fast moving SKUs buy you the seconds your slowest sync needs.
Webhooks Are At Least Once, So Everything Downstream Must Be Idempotent
Marketplace order webhooks retry. They arrive out of order, they arrive twice, and occasionally they arrive an hour late after the channel had an incident. If your order ingestion is not keyed on the channel's own order id with a uniqueness constraint behind it, you will eventually ship something twice.
The same rule applies to inventory adjustments. Send deltas and you will drift. Send absolute quantities with a version or timestamp and let the receiver discard anything older than what it already applied.
Rate Limits Decide Your Sync Frequency, Not Your Ambition
Every channel meters you differently. Some give you a leaky bucket, some a fixed window, some a cost per query on a GraphQL endpoint. A naive loop that pushes every SKU on every change hits the ceiling on your first busy day and then silently falls behind.
What works is a change queue with coalescing. If a SKU changed six times in thirty seconds, you owe the channel one update, not six. Prioritise the queue by how close a SKU is to zero, because that is where an oversell actually happens.
Reconciliation Is Not Optional
Even with all of the above, drift happens. A manual edit in a channel dashboard, a failed retry that exhausted, a partial refund that never fired an event. The systems that stay correct run a periodic full comparison between the source of truth and each channel, log the differences, and alert when the count crosses a threshold rather than fixing silently.
Silent auto correction is how a real bug hides for three months.
The Takeaway
Multichannel is one catalog, one authoritative stock number, one order queue, and a lot of careful plumbing between them. None of it is glamorous and all of it is what decides whether the second channel earns money or just generates support tickets.
If you want the business side of the same picture, covering channel selection, pricing per channel and the analytics that make it legible, we wrote it up in our guide to multichannel selling.