A fashion and beauty chain with hundreds of stores loses sales in two cases: an item appears on the site but is unavailable in the store, or vice versa. The cause is separate tracking of online and offline inventory. An omnichannel storefront solves this by letting online orders use the same physical stock as the store register and reserving a specific unit at the location closest to the customer. Below is a breakdown of what this approach gives Saleor, an open-source headless commerce API (BSD license), based on its documentation. This is not a KT.Team case study, but an overview of the tool's capabilities.
What the network gets: business results
- Click-and-collect from any store. Each store is registered as a warehouse and becomes a pickup point. The customer places the order online and picks it up at a convenient location, with no separate integration for "pickup."
- Unified stock instead of two separate inventories. One API returns product availability across all warehouses at once. A size "38, black" is visible where it is physically in stock, which reduces the share of orders canceled because the item is unavailable.
- Reserve during checkout. While the customer is checking out, the item is blocked. For scarce sizes and limited beauty lines, this prevents selling the last unit twice.
Multi-warehouse stock model
In Saleor, stock (`Stock`) is a link between "product variant ↔ warehouse ↔ quantity." Each variant (for fashion, SKU size×color; for beauty, shade×volume) stores stock separately for each warehouse (Stock Overview). A network of hundreds of stores is modeled as hundreds of warehouses; each store's POS and the online storefront work from the same stock record.
Each stock record stores three values: `quantity` (total), `quantityAllocated` (reserved for confirmed orders), and `quantityReserved` (blocked during checkout). This separation is the basis of accurate availability: the storefront shows not "how much is on the shelf," but "how much can actually be sold right now."
A warehouse is linked to a sales channel (`channel`); one warehouse can serve multiple channels. This makes it possible to run different channels (for example, RU retail and wholesale) on a single stock pool without duplicating data.
Checkout-time reservation
Saleor supports optional stock reservation for a cart for a configurable time (Stock Reservation). When a customer adds an item to the cart, units are deducted from the available quantity seen by other users. Scenarios:
1. Checkout is completed within the allotted time - the temporary reserve becomes a permanent allocation for the order.
2. Time runs out - the reserve is released, and the item becomes available to others again.
3. The `stockReservationExpires` field in the `Checkout` GraphQL type returns the reserve expiration time in ISO-8601, so the frontend can show a timer like "the item is reserved for you for another N minutes".
The reserve is configured separately for authenticated and anonymous customers in Site settings -> Checkout Configuration. For fashion with its size sales and for limited beauty drops, this removes the classic conflict of "two people bought the last item."
Click-and-collect: store as pickup point
Click-and-collect mode is set at the warehouse level via `clickAndCollectOption` with three values (Stock Overview):
- Local stock — fulfillment only from this store's own stock. The customer sees "available for pickup here today".
- All warehouses — a pickup order can be assembled from stock across all warehouses in the channel (the item is delivered to the pickup point).
- Disabled — this location does not support pickup.
When click-and-collect is selected, Saleor uses the warehouse address to calculate taxes, which is correct for a network with locations in different tax jurisdictions. For the customer, this means a real answer to the question "which nearby store has my size right now".
Order routing and warehouse priority
Saleor can fulfill one order from multiple warehouses and create multiple shipments for a single order. The key inventory control feature is "control stock allocation priority among warehouses": the order of stock deduction across warehouses is configurable. The network can define logic such as "first the store closest to the customer, then the regional hub, then the central warehouse," and the order automatically reserves the item at the right location.
Stock events are published via webhooks: `PRODUCT_VARIANT_OUT_OF_STOCK`, `PRODUCT_VARIANT_BACK_IN_STOCK`, `PRODUCT_VARIANT_STOCK_UPDATED`. They fire when availability changes across the channel's warehouses, which makes it possible to sync stock with external systems (ERP, POS software) without polling.
Architecture Framework
Saleor is a headless API: the business logic for routing, notifications, and POS integrations is moved into separate services around the core via webhooks and GraphQL, without forking Saleor itself. This follows the principle of minimal core modification and preserves portability: the team or contractor can change without rewriting the platform. Inventory is tracked in one place, while channels, cash registers, and the storefront are consumers of a single API.
Business process conclusion
The "unified stock + reserve + pickup" process in Saleor looks like this: the online order queries the multi-warehouse model -> the nearest in-stock location is chosen according to warehouse priority -> the unit moves from `quantity` to `quantityReserved` during checkout -> after payment, the reserve becomes an allocation for the order -> the store-warehouse in click-and-collect mode hands over the item. The result for the network: fewer cancellations due to "out of stock," no double-selling of scarce sizes and shades, and each of hundreds of stores works as an online pickup point on a shared stock pool.
