1C-Bitrix Integration with MyWarehouse

Integration of 1C-Bitrix with MoySklad

An online store on 1C-Bitrix and MoySklad (cloud commerce management system) is a common combination for small and medium businesses. However, Bitrix lacks a native integration module, and ready-made marketplace solutions cover 60-70% of scenarios. The remainder — non-standard property mapping, stock synchronization across warehouses, characteristic processing — requires custom development. Let's examine the integration architecture, MoySklad API, and typical issues.

What We Synchronize

Bitrix ↔ MoySklad integration typically includes four data streams:

"MoySklad as master" for products is typical. Content manager works in MoySklad, site receives up-to-date data. Reverse product synchronization (Bitrix → MoySklad) is rarely needed and creates conflict risks.

MoySklad API: Remap API 1.2

MoySklad provides REST API (JSON API 1.2) at https://api.moysklad.ru/api/remap/1.2/. Authentication — Basic Auth or Bearer Token.

Key endpoints:

• GET /entity/product — product list. Supports filtering (filter=updated>2024-03-01), pagination (limit, offset), expansion of nested entities (expand=group,productFolder).
• GET /entity/assortment — unified list of products, modifications, kits, and services. More convenient than product when you need everything at once.
• GET /report/stock/all — stock for all products. Can filter by warehouse (stockstore).
• POST /entity/customerorder — creating customer order.
• GET /entity/customerorder/{id} — getting order with statuses.

API Limitations:

• Rate limit: 45 requests per 3 seconds per account. Exceeding returns HTTP 429. Parser should account for delays.
• Maximum 1000 objects per response. For full catalog export, pagination is needed.
• Webhook notifications (MoySklad → your server) — available but unreliable: no delivery guarantee, no retries. For critical data (stock), use polling.

Product Synchronization

Incremental synchronization algorithm:

1. Request GET /entity/assortment?filter=updated>${lastSyncTime}&limit=1000.
2. For each product, find correspondence in Bitrix iblock by external code (XML_ID = UUID of product in MoySklad).
3. If found — CIBlockElement::Update() with updated fields.
4. If not found — CIBlockElement::Add().
5. Save lastSyncTime = now() in b_option.

Field Mapping — core of integration. Correspondence table:

Characteristics (modifications) in MoySklad are variant inside product. In Bitrix they correspond to trade offers (SKU) in a separate iblock. Each variant → SKU-iblock element with binding to parent product via CHL_LINK (property CML2_LINK).

Stock Synchronization

Stock is the most sensitive stream. Selling out-of-stock product — direct losses.

Call GET /report/stock/all with filter by warehouses participating in online sales. Result contains assortmentId and quantity. Update CATALOG_QUANTITY field in b_catalog_product or via \Bitrix\Catalog\ProductTable::update().

For displaying stock by warehouses on site (e.g., "in stock at Lenin Store"), use Bitrix warehouse accounting mechanism: module catalog, table b_catalog_store_product. Each MoySklad warehouse maps to Bitrix warehouse (b_catalog_store).

Frequency: every 5 minutes via cron script. Bitrix agents for this task are unsuitable — they're tied to hits and don't guarantee interval.

Order Transmission

When order is placed in Bitrix (event OnSaleOrderSaved or OnSaleComponentOrderComplete), create order in MoySklad 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
    }
  ]
}

Counterparty (agent) — buyer. On first order, create via POST /entity/counterparty, on repeat — search by email/phone. Save counterparty UUID in custom order property in Bitrix or in user UF_-field.

Error Handling and Queue

Network is unreliable, MoySklad API sometimes returns 500. For orders use queue: on send error, save order to parser_queue table (or b_sale_order with "not sent to MoySklad" flag), agent retries every 5 minutes. Max 5 attempts, then — notify manager.

For products and stock, queue isn't needed — next sync cycle will pick up changes.

Timelines