Integration of 1C-Bitrix with WMS Systems
When an online store transitions from manual stock management to a warehouse management system (WMS), the first problem is always stock desynchronisation. An order is placed on the site, a reserve is set in 1C-Bitrix, but the WMS has no knowledge of it yet. By the time picking begins, the item is not in the expected bin. Integration solves exactly this loop — not merely "transfers data".
What needs to be synchronised
The standard data exchange between 1C-Bitrix and a WMS covers three data streams:
Stock levels and reservations. The WMS is the source of truth for physical availability. Bitrix receives stock levels and updates b_catalog_product (fields QUANTITY, QUANTITY_RESERVED). Synchronisation frequency is critical: at a throughput of 200+ orders per day, a 15-minute delay already creates oversell situations.
Orders. New order from Bitrix → WMS for reservation and picking. Picking statuses from WMS → Bitrix to update the customer's order status. Atomicity is essential here: an order is either accepted by the WMS or it is not — "hanging" transfers are not acceptable.
Product catalogue. SKUs, barcodes, units of measure, packaging. Master data is usually maintained in ERP/1C, and the WMS and Bitrix synchronise from it.
Integration architecture
There is no direct "Bitrix ↔ WMS" API connector — each WMS has its own API or supports EDI/XML formats. The choice of architecture depends on reliability requirements and real-time needs:
Polling (scheduled). An agent in Bitrix queries the WMS API every N minutes, retrieves changes, and updates stock levels. A simple scheme, but with a lag equal to the polling interval. Implemented via a handler in \Bitrix\Main\EventManager or a custom agent.
Webhook/event queue. The WMS sends an event on every stock change. Bitrix receives it via a REST endpoint (a custom controller or the Bitrix REST API). Lower latency, but a queue (RabbitMQ, Redis Streams) is needed to avoid losing events under load.
Via a 1C broker. If 1C:Enterprise is part of the chain, the exchange flows through it: Bitrix ↔ 1C (standard CommerceML/REST) ↔ 1C ↔ WMS (via exchange rules or the 1C WMS direct API). A heavier architecture, but with control on the 1C side.
Technical implementation details on the Bitrix side
Stock levels are updated via \Bitrix\Catalog\ProductTable::update() or the lower-level CCatalogProduct::Update(). After an update, cache invalidation is essential: \Bitrix\Catalog\Catalog::clearProductCache($productId). Without this, the site will display stale stock data from cache for another 30–60 minutes.
Reservation on order creation: the \Bitrix\Sale\Order object automatically sets a reservation via \Bitrix\Sale\Basket::setField('RESERVE_QUANTITY') when saved. If the integration updates stock directly in the database bypassing the API, reservations break. Always use the public API of the sale module.
To forward orders to the WMS, attach to the OnSaleOrderSaved or OnSaleStatusOrderChange event — depending on the trigger that should initiate WMS picking. The event is processed synchronously within the same HTTP request, so long WMS API calls should be offloaded to a queue.
Common problems
Duplicate orders in WMS. Occurs when the network is unstable and Bitrix retries the request on timeout. Solution: idempotent requests using the Bitrix ORDER_ID as an external key in the WMS — re-sending updates the existing record rather than creating a new one.
Unit of measure mismatch. Bitrix stores quantities in pieces; the WMS works with pallets and boxes. If the mapping table Bitrix unit → WMS unit is not populated, stock levels are transferred incorrectly. Solved by a conversion reference in the integration layer.
Timeout during bulk stock updates. The WMS returns 10,000 positions in a single request; Bitrix processes them in batches using set_time_limit() and \Bitrix\Main\Application::getInstance()->getDbConnection()->startTransaction().
Estimated timelines
| Scenario | Timeline |
|---|---|
| Simple integration: scheduled stock sync | 2–4 weeks |
| Two-way order and stock exchange | 4–8 weeks |
| Integration via 1C broker with complex logic | 2–4 months |
Pricing is calculated individually — it depends on the specific WMS system's API, the volume of the product catalogue, and real-time requirements. We start with an audit of current processes and the WMS technical documentation.