1С-Битрикс with МойСклад Integration: API, Products and Orders Sync

We often encounter a situation where an online store on 1С-Битрикс uses МойСклад for trade management, but there is no standard integration module. Off-the-shelf solutions from the marketplace cover 60–70% of scenarios. The rest — non-standard property mapping, warehouse stock synchronization, and attribute handling — requires custom development. Our experience shows that a properly configured integration pays for itself by eliminating manual entry and errors. Let's dive into the architecture, МойСклад API, and typical problems. In this article, we'll describe in detail the setup process for synchronizing products, stocks, and orders using МойСклад JSON API 1.2. You'll learn how to avoid common mistakes and which tools to use for reliable operation.

What We Synchronize

The Битрикс ↔ МойСклад integration usually involves four data streams:

The direction "МойСклад as master" for products is typical. A content manager works in МойСклад, and the site receives up-to-date data. Reverse synchronization (Битрикс → МойСклад) is rarely needed and creates conflict risk.

How the МойСклад API Remap 1.2 Works

МойСклад provides a REST API (JSON API 1.2) at Remap API 1.2. Authorization is via Basic Auth or Bearer Token.

Key endpoints:

• GET /entity/product — list of products. Supports filtering (filter=updated>${lastSyncTime}), pagination (limit, offset), and expanding nested entities (expand=group,productFolder).
• GET /entity/assortment — combined list of products, modifications, kits, and services. More convenient than product if you need everything at once.
• GET /report/stock/all — stock balances for all products. Can be filtered by warehouse (stockstore).
• POST /entity/customerorder — create a customer order.
• GET /entity/customerorder/{id} — get an order with statuses.

API limitations:

Why Proper Field Mapping Matters

Product synchronization is the heart of the integration. Algorithm for incremental sync:

1. Request GET /entity/assortment?filter=updated>${lastSyncTime}&limit=1000.
2. For each product, find the corresponding element in the Битрикс information block by external code (XML_ID = product UUID in МойСклад).
3. If found — CIBlockElement::Update() with updated fields.
4. If not found — CIBlockElement::Add().
5. Save lastSyncTime = now() in b_option.

Field mapping — the core of integration. Correspondence table:

Characteristics (modifications) in МойСклад are variant inside a product. In Битрикс, they correspond to trade offers (SKU) in a separate information block. Each variant → SKU information block element linked to the parent product via CHL_LINK (property CML2_LINK).

Stock Synchronization

Stock is the most sensitive stream. Selling a product with zero stock is a direct loss. We call GET /report/stock/all with a filter for warehouses that participate in online sales. The result contains assortmentId and quantity. We update the CATALOG_QUANTITY field in b_catalog_product or via \Bitrix\Catalog\ProductTable::update().

To display per-warehouse stock on the site (e.g., "in stock at Lenin store"), use Битрикс warehouse accounting: catalog module, table b_catalog_store_product. Each МойСклад warehouse maps to a Битрикс warehouse (b_catalog_store). Frequency: every 5 minutes via a cron script. Битрикс agents are not suitable for this task — they are tied to hits and do not guarantee the interval.

Order Transfer

When an order is placed in Битрикс (event OnSaleOrderSaved or OnSaleComponentOrderComplete), we create an order in МойСклад via POST /entity/customerorder. Request body structure:

{ "organization": {"meta": {"href": "...entity/organization/{id}"}}, "agent": {"meta": {"href": "...entity/counterparty/{id}"}}, "positions": [ { "assortment": {"meta": {"href": "...entity/product/{id}"}}, "quantity": 2, "price": 150000 } ] } 

The counterparty (agent) is the buyer. For the first order, create via POST /entity/counterparty; for repeat orders, search by email/phone. The counterparty UUID is stored in the Битрикс order user property or in the user UF_ field.

Error Handling and Queue

The network is unreliable; МойСклад API sometimes responds with 500. For orders, use a queue: on send error, save the order to the parser_queue table (or b_sale_order with a flag "not sent to МойСклад"), and an agent retries every 5 minutes. Maximum 5 attempts, after which notify the manager. For products and stock, a queue is unnecessary — the next sync cycle will pick up changes.

What’s Included in the Work

• Analysis of the catalog structure and creation of a mapping map
• Development of synchronization scripts for products, prices, and stock
• Setup of order and counterparty transfer
• Creation of integration documentation
• Training of staff on system operation
• Technical support after launch

Our team has over 10 years of experience and 50+ successful integrations. For an accurate timeline and cost estimate, contact us.

Timeline

Order a consultation on integration, and we will evaluate your project.