1C-Bitrix and Inflow WMS: Integration Architecture, Mapping, Labeling

We integrate 1C-Bitrix with Inflow WMS to streamline warehouse operations and eliminate order processing errors. Inflow WMS is a warehouse system for medium and large e-commerce: address storage, picking zone management, SSCC labeling support. Integrating with 1C-Bitrix here is more complex than with typical cloud WMS — Inflow is often deployed on-premise, has a configurable API, and requires agreement on the exchange scheme tailored to the specific system configuration. We have accumulated experience in such projects and guarantee that the final solution will be resilient to loads and errors.

Recently, an electronics online store with a turnover of 500 orders per day approached us. Their Inflow WMS is deployed locally, and the integration with Bitrix via custom cron scripts periodically lost orders on picking errors. The client was losing up to 5% of revenue due to unhandled failures. We designed the exchange through Inflow's REST API with status mapping and retry queues. Within a month, the number of lost orders dropped to zero, saving the client an estimated $15,000 monthly.

Exchange Architecture with Inflow WMS

Inflow provides a REST API or SOAP interface depending on the deployment version. Most modern installations use REST with JSON. Authentication via API key in the X-API-Key header or OAuth2. Inflow WMS handles peak loads 2 times better than cloud alternatives due to local deployment and optimized task distribution.

Typical Inflow endpoints:

• GET /api/v1/stock — current stock by warehouse/zones
• POST /api/v1/orders — create a picking order
• GET /api/v1/orders/{id}/status — order execution status
• PUT /api/v1/orders/{id}/cancel — cancel a picking order

A key difference from simpler WMS: Inflow separates the concepts of picking order and customer order. One customer order can generate multiple picking orders — when working with multiple storage zones or different carriers.

How Is Order Status Mapping Performed?

The most labor-intensive part is mapping statuses between systems. In Bitrix, order statuses are freely configurable (b_sale_status reference). In Inflow, the status machine is fixed: NEW → ASSIGNED → PICKING → PICKED → PACKING → SHIPPED → DELIVERED.

A mapping table is needed to translate Inflow statuses to Bitrix statuses:

We store the mapping table in the integration module settings so it can be changed without deployment. This allows adapting the scheme to the client's business processes within an hour, not a day. Source: official Inflow WMS documentation.

Stock Synchronization Considering Address Storage

In address-based WMS systems, "stock" is not just a number but a distribution across bins. For an online store, only the available for sale quantity matters: qty_on_hand - qty_reserved - qty_in_picking.

We query Inflow via GET /api/v1/stock?warehouse=main&available_only=true. We obtain aggregated stock. We update in Bitrix via \Bitrix\Catalog\ProductTable::update() with cache invalidation. For more details on updating products, see the Bitrix documentation.

The frequency of stock synchronization is a separate discussion with the client. High-turnover warehouses (100+ picks per hour) require synchronization every 2–5 minutes or a switch to events. For less loaded ones, a 15-minute interval via a Bitrix agent is sufficient. We recommend starting with 5 minutes and adjusting based on load.

Why Is Picking Error Handling Important?

Inflow may return a PICKING_ERROR status — item not found in the specified bin, position unavailable. In this case, the order in Bitrix should receive a special status and a task for the manager. This is not a standard situation — it is handled with custom logic on the Inflow status update event.

A typical case: a manager placed an order for an item whose stock hasn't been updated yet. WMS returns an error when attempting to reserve. The integration must: notify the manager, release the reserve in Bitrix, suggest an alternative or cancellation. Without handling this scenario, a "silent" error turns into an unfulfilled order without notification. Our guarantee: we always cover this scenario.

Labeling and Barcodes

If the warehouse handles labeled goods (Chestny Znak, SSCC), integration becomes more complex: when transferring an order to Inflow, the labeling codes must be specified, and upon shipment, the list of used codes must be obtained for transmission to the fiscal data operator. This is a separate exchange loop involving b_catalog_product_barcode on the Bitrix side. We have implemented such projects for networks with a turnover of 1000+ orders per day, reducing compliance errors by 80%.

How We Design Integration: Step-by-Step Plan

1. Audit of current Inflow WMS configuration and API scheme — 2 days.
2. Design of exchange scheme and status mapping considering business processes.
3. Development of integration module for Bitrix: custom agents, event handlers, retry queues.
4. Setup of test environment and load testing (simulating 1000+ concurrent requests).
5. Phased launch: first stock synchronization, then orders, then error handling.
6. Handover of operational documentation and training for managers.
7. Support during launch phase (2 weeks).

What's Included

• Documentation of exchange scheme and status mapping
• Configuration of API access for Inflow and Bitrix
• Turnkey integration module development
• Load testing simulating peak scenarios
• Manager training on the new system
• Technical support during launch (2 weeks)

If you want a reliable integration, request a warehouse audit — it takes only 2 days.

Timeline Estimates

We have 8+ years of experience in WMS integrations and have completed 25+ projects for e-commerce clients with turnovers from $1M to $50M. The integration typically pays for itself in 3–4 months by reducing errors and speeding up processing. To get a consultation and preliminary estimate, contact us.