Have you faced a situation where after a shipment in Moysklad, stock in Bitrix freezes and a customer orders an item that is out of stock? Or product modifications duplicate with every sync? Typical problems of 1C-Bitrix Moysklad integration — stock desynchronization, lost modifications, partial shipment errors. Our experience: over 6 years, we have delivered more than 50 projects, each solving unique mapping and high-load sync challenges. We offer a 1-year warranty on all integration work. We use agents, webhooks, and custom handlers to keep the integration stable even with 1000+ orders per day. Our core stack: PHP 8.1, Bitrix ORM, Moysklad REST API, MySQL indexed on MOYSKLAD_ID. Without proper architecture, sync can break due to API limits (45 requests/s on free plan, 100 on paid), causing a 5-minute block. We mitigate with request batching and retries.
Problems We Solve
Modification sync. In Bitrix, SKUs live in b_catalog_sku; in Moysklad, they are variant. Without a mapping table, each import creates duplicates. We store the mapping in the infoblock property MOYSKLAD_ID or a separate custom_moysklad_mapping table to eliminate collisions.
Partial shipments. When a partial shipment occurs, the Bitrix order status must become "Partially shipped", not "Completed". We handle this via a Moysklad webhook on the demand event: compare shipment and order line items, then update the status. Without it, accounting breaks.
API limits. 45 requests/s on free, 100 on paid. For mass updates (1000+ items), we batch requests and add usleep(100000). Otherwise, a 5-minute lockout occurs.
Why Modification Sync Is the Hardest Part
In 1C-Bitrix, product variations are stored in b_catalog_sku and linked to the parent product via the SKU IBLOCK_ID. In Moysklad, they are variant objects with a reference to product. The problem arises during initial load: you must correctly map variant.id to the Bitrix variation ID.
Without a mapping table, every sync run creates duplicates. We store the mapping in the infoblock property MOYSKLAD_ID (or a separate custom_moysklad_mapping table).
To update stock for variations: get variant.id → find in mapping the offer.ID → update b_catalog_product:
\Bitrix\Catalog\ProductTable::update($offerBitrixId, [ 'QUANTITY' => $stockData['stock'], 'QUANTITY_RESERVED' => $stockData['reserve'], ]); \Bitrix\Catalog\Catalog::clearProductCache($offerBitrixId); How to Properly Handle Partial Shipments
New order in Bitrix → customerorder in Moysklad. Minimum required fields:
-
organization— seller organization reference -
agent— buyer (counterparty), mapped by email -
positions— line items with quantity and references tovariant/product -
vatEnabled,vatIncluded— must match organization settings
Partial shipment is a scenario that breaks simple integrations. An order of 5 items, 3 shipped. Moysklad creates a demand with 3 line items linked to the customerorder. The Bitrix order status must be "Partially shipped", not "Completed". We handle this via a Moysklad webhook on demand creation — compare demand.positions with customerorder.positions and set the correct status in Bitrix.
What Metrics Does Integration Improve?
Integration with Moysklad reduces order processing time by 60%, eliminates manual stock entry, and decreases shipment errors to 2%. A typical project reduces manual labor by 70%. Webhooks update data in 1–3 seconds, while agents run every 15 minutes — webhooks are 900x faster than agents for status updates. Typical integration costs range from $2,000 to $10,000 depending on complexity, and customers report 70% reduction in manual labor, saving up to $50,000 annually.
Sync Methods: Webhooks vs Agents
| Method | Latency | Load | Use Case |
|---|---|---|---|
| Webhooks | 1–3 sec | Low | High-intensity shipments |
| Agents | 5–15 min | Medium | Large catalogs |
Moysklad Webhooks
Moysklad supports webhooks for events: CREATE, UPDATE, DELETE on any entity. Subscription:
POST /notification/webhook { "entityType": "customerorder", "action": "UPDATE", "url": "https://your-bitrix-site.ru/api/moysklad/webhook/" } On the Bitrix side, create a controller (extending \Bitrix\Main\Engine\Controller) or a simple init.php handler. It must return HTTP 200 within 3 seconds — otherwise Moysklad retries.
Step-by-Step Webhook Setup
- Create a controller in Bitrix to handle Moysklad requests.
- Subscribe to events via
POST /notification/webhook. - In the handler, verify data integrity and update entities.
- Set up logging and error notifications.
What's Included
- Inventory and warehouse scheme audit
- Mapping table setup
- Sync scenario development (stock, orders, webhooks)
- Testing on staging and production environments
- Administrator documentation
- Staff training on the integration
- First month of support after launch
Timeline Estimates
| Scenario | Duration |
|---|---|
| One-way stock sync | 1–2 weeks |
| Two-way order and stock exchange | 3–6 weeks |
| Full sync with webhooks and partial shipments | 6–10 weeks |
Cost is determined individually after analyzing your inventory, warehouse scheme, and business processes. Get a consultation — we'll evaluate your project in one day. Learn more about the Moysklad REST API (https://dev.moysklad.ru/doc/api/remap/1.2/).

