This is an overview article, not a KT.Team case study. Below is an open review of what has been publicly done on MuleSoft (Mule ESB / Anypoint Platform) in retail and e-commerce: how the online store, POS, warehouse, CRM, and logistics are connected by an API layer and what business result it delivers. All figures come from public sources, with links at the end.
Business problem: the channel exists, but there is no single inventory view
A typical retail company accumulates systems one by one: a site on an e-commerce platform, in-store POS terminals, a warehouse (WMS), ERP with inventory balances, CRM with customer data, and a separate delivery service. Each knows its own version of the truth about stock and orders. The result is overselling, online order rejections, the inability to fulfill an order from the nearest store, and no single customer record.
The business result is expressed in three metrics: stock accuracy across all channels, time from order placement to picking start and speed of rolling out a new feature to a new store/market. MuleSoft addresses exactly these through the API-led connectivity approach.
How the API layer is structured (System / Process / Experience)
MuleSoft does not suggest rewriting the ERP or the e-commerce core. Business logic is moved into APIs alongside the systems, using three layers (79Consulting):
- System APIs — thin adapters on top of source systems: e-commerce, ERP, CRM, POS, WMS, PIM/MDM, 3PL. They encapsulate data access and contain no business logic.
- Process APIs — orchestration: "single inventory view", "order routing", "fulfillment location selection." This is where the omnichannel logic lives.
- Experience APIs — channel-specific front ends: web, mobile app, checkout, customer account.
The key idea is portability: System APIs are reused across processes. At Lotus's, this delivered 70% API reuse, which directly reduced development time and cost (MuleSoft / Lotus's).
Single product inventory view (single inventory view)
MuleSoft published the reference implementation as part of Accelerator for Retail (Use case 4 - Real-time inventory management). It connects Salesforce B2C Commerce, SAP S/4HANA, Salesforce Service/Sales Cloud, and PIM/MDM (Anypoint Exchange).
The logic behind the single inventory view is published step by step:
1. The customer selects a product and enters a postal code on the storefront.
2. Inventory Process API queries MDM and finds the product by a universal product ID (mapping different channel SKUs to one).
3. The Process API calls SAP S/4HANA Product Availability System API for real-time stock.
4. The same result is returned to both the B2C storefront and the Salesforce interface, with availability by specific store.
Accelerator components out of the box: a System API for B2C Commerce, for availability, products, and orders in S/4HANA; a Process API for inventory; and an Experience API for B2C and Salesforce.
What this delivers in real retail: Lotus's on this architecture reached 98% inventory accuracy across more than 2,000 stores and 250,000 active SKUs per store plus warehouses. GANT through an inventory API shows availability in a specific store at the moment the customer clicks, matching store data with retail system stock; thanks to reuse, this function was rolled out to five markets three times faster, than with point-to-point (GANT).
End-to-end order (omnichannel order)
The second process is a single order. An order from any channel (web, mobile app, store) enters one OMS/ERP, and the Process API decides where to ship from: the warehouse, the nearest store (ship-from-store), or pickup (BOPIS). In the Accelerator, order creation orchestration runs in SAP S/4HANA, with delivery set to zero for pickup.
The business impact shows SMCP (Sandro, Maje, Claudie Pierlot): using API-led connectivity, the company built a single customer profile by online and offline behavior and set a goal to reduce the time from order to picking start from 2.5 hours to minutes, to deliver the order to the customer in 2 hours (SMCP). This is end-to-end order processing: the sales channel is decoupled from the fulfillment point.
No-core-modification approach
An important detail for long-term operations: e-commerce, SAP, and CRM all remain off-the-shelf systems, while omnichannel logic lives in the adjacent API layer on international standards (REST, OAuth, a single product ID through MDM). This is loosely coupled and portable: a new channel or market is added by reusing existing System APIs, not by building another point-to-point integration. That is why GANT and Lotus's can move so quickly.
Diagram
A three-layer architecture: at the bottom, System APIs over e-commerce, ERP (SAP S/4HANA), CRM, POS, WMS, PIM/MDM, and 3PL; in the middle, two Process APIs - Unified Stock (aggregates availability by universal product ID) and End-to-end Order (routes the order into OMS and selects the fulfillment point: warehouse / store / pickup); at the top, Experience APIs for web, app, checkout, and CRM. All channels query the same stock and write to the same order; System APIs are reused across processes.
Business process conclusion
An API layer on MuleSoft turns disconnected systems into one flow: see stock, place the order in any channel, then fulfill from the best location. It should be measured by three numbers from public examples: stock accuracy (98% at Lotus's), order-to-pick time (2.5 hours to minutes at SMCP), and the share of reusable APIs (70%, which speeds up new markets by multiples). If these metrics do not improve, the integration exists for its own sake.
