Omnichannel Sales Integration

Starting point — an integration that “worked”, yet nobody trusted it

The PrestaShop store sold across three channels: its own storefront, Allegro and Amazon. The marketplace integration existed, but it was unreliable in the details that decide everything in e-commerce. The same order landed in the store twice whenever an API response timed out and the system retried the request. Stock levels updated at different moments, so occasionally a product sold that was not physically available. The team stopped trusting the automation and checked every order in two systems — the integration added work instead of saving it. Problems surfaced through customer complaints, not through the system. This is the classic state where an integration formally exists but has been organisationally abandoned, because nobody trusts it.

Order idempotency — duplicates eliminated at the source

Every marketplace order carries its own identifier. We introduced an idempotency key based on that identifier and a check before saving: if an order with the same identifier already exists, the system updates it instead of creating a new one. That removed duplicates at the source — not by filtering them later, but by not letting them come into existence. Idempotency is the foundation of every resilient integration: the network may lose a response, but the system must not lose an order or duplicate it when a request is retried.

A retry queue instead of parallel requests

Marketplace API calls go through a rate-limited queue rather than being fired in parallel — so we never exceed API limits and never lose jobs. The queue has three priority levels: orders and bestseller stock, stock of remaining products, then descriptions and prices. When the API returns a transient error (rate limit, timeout, brief unavailability), the job returns to the queue with exponential backoff instead of being lost. Every retry is logged, so unstable integrations become visible.

Stock buffer and real-time reservation

External channels see stock reduced by a safety buffer, and a marketplace order immediately reserves the item in the store. The buffer is configurable per product: larger for bestsellers, smaller or zero for slow-moving items. This simple mechanism removes the most expensive scenario in multi-channel selling — selling goods you do not have — and buys time to reconcile stock levels without risking complaints.

Event log and drift alerts — monitoring that works

Every event — an order received, a stock change, an API error, a retry — lands in the event log. A separate mechanism compares stock between the store and the channels and raises an alert when drift exceeds a threshold. That changed problem detection from “we will hear it from a complaint” into “we will know within the hour”. In practice monitoring turned out to be more important than the integration itself: an integration without alerts is a system whose failures you learn about from your customer.

Testing on a data sample before go-live

Before running the process on the full dataset, we pushed a sample of orders through it, including edge cases: bulk orders, cancellations after reservation, returns and discontinued products. The most time-consuming part was not the code but mapping product variants and reconciling status differences between channels. Testing on a data sample caught those differences before production, not after the first wave of orders.

What omnichannel selling actually is

Omnichannel selling is a model where customers buy across many channels — the online store, marketplaces, a mobile app, a physical shop — and every channel works from shared data: stock levels, orders, prices and customer history. The key word is “shared”: in omnichannel, channels are not merely next to each other, they are synchronised in near real time. The foundation of that model is system integration — without it, omnichannel exists only in the name, while employees retype data between panels by hand.

Omnichannel vs multichannel — the difference that changes architecture

Multichannel means selling across many channels run independently: separate stock, separate descriptions, often separate teams. Omnichannel means the same channels bound together by a shared data layer and shared processes — one source of truth for stock, one order queue, one customer history. The difference is architectural, not marketing: multichannel can be run by hand up to a point, while omnichannel cannot exist without integration. Keep that distinction in mind at every rollout decision — selling on Allegro and Amazon without synchronisation is still multichannel.

Lessons for your store

An integration without monitoring does not exist — if you have no alert on stock drift, you do not know whether the integration works; you only know you have not received a complaint yet. Duplicates are a design problem, not an operational one — they cannot be handled by hand in a durable way; they must be eliminated through an idempotency key. Team trust is a metric — the biggest gain was not the 40% faster handling, but the fact that the team stopped verifying every order by hand; until that happens, automation never pays for itself no matter how well it works.

How long it takes and what it costs

Rebuilding the flow with idempotency, a queue and monitoring usually takes 3–6 weeks, depending on the number of channels and catalogue quality. Mapping product variants and testing edge cases takes the most time. Cost depends on scope: e-commerce integrations start at a few thousand PLN, while projects with a dedicated middleware and ERP reach tens of thousands of PLN net. If you run a multi-channel store and want a ballpark budget for your case, get in touch — I prepare quotes after a free scope analysis.

Frequently asked questions