Integrating 1C-Bitrix with Bitrix24 CRM via REST API

Integrating 1C-Bitrix with Bitrix24 CRM

We see this daily: an online store on 1C-Bitrix takes orders while the sales team works in Bitrix24 CRM. Managers manually transfer data between systems — losing orders, duplicating contacts, and missing customer history. The ready-made solution is REST API + webhooks between two products from the same vendor, but configuring it correctly is trickier than it seems. Our experience shows: automation via REST API cuts manual data transfer time by 10× and eliminates errors. Savings on manual labor reach 80% — for a store with 500 orders per month, that's equivalent to 30 hours of manager work. In this article, we'll break down key technical aspects: method selection, status mapping, conflict handling, and scaling via a queue.

Which REST API Methods Do You Need?

Bitrix24 provides a REST API via OAuth 2.0 or inbound webhooks. 1C-Bitrix communicates through the bitrix24connector module (if installed) or directly via \Bitrix\Main\Web\HttpClient. Key methods:

How to Set Up Two-Way Sync Without Conflicts?

One-way transfer (site → CRM) is quick. Problems arise with two-way: manager changes deal status in Bitrix24 → site must update order status. Simultaneously, customer changes order on site → CRM must update deal.

Case study. A building materials online store with 200–300 orders per day. After launching two-way sync, within 3 days we found order statuses "floating" — an order paid on site reverted to "new" status from CRM. Cause: the webhook from Bitrix24 arrived after the site event and overwrote the status without priority check.

Solution — a 'source-of-truth' field (source_system) in status mapping:

// On receiving webhook from Bitrix24 — check timestamp $localOrder = CSaleOrder::GetByID($orderId); $localUpdated = strtotime($localOrder['DATE_UPDATE']); $b24Updated = strtotime($webhook['data']['FIELDS']['DATE_MODIFY']); if ($b24Updated > $localUpdated) { // Update order on site CSaleOrder::StatusOrder($orderId, $newStatus); } 

Why Status Mapping Matters?

Order statuses in 1C-Bitrix are stored in b_sale_status, deal statuses in Bitrix24 are pipeline stages (crm.status.list). Mapping isn't one-to-one: Bitrix24 may have 10 stages, site may have 5 statuses. We create a mapping table stored in a custom table or module settings.

If you have custom statuses like "awaiting assembly" or "reserved", they need to be added as extra stages in the Bitrix24 pipeline. We use crm.status.add to create new statuses, then link them via mapping.

Why a Request Queue Is Critical?

Bitrix24 REST API has a rate limit: 2 requests per second on cloud plans. During order spikes, direct synchronous calls hit the limit. Using a queue reduces errors 5-fold compared to synchronous calls. Proper architecture:

1. Event on site (OnSaleOrderSaved) places task into a queue table.
2. Bitrix agent processes queue every 30 seconds in batches at 2 req/s.
3. On error, the record stays in the queue with an incremented retry counter (max 5).

We also integrate monitoring: if the queue exceeds 1000 items, an alert triggers, allowing early detection of network or API issues.

How the Integration Is Done?

We break it into stages. First, we analyze current business processes: which entities to sync, which statuses are used, data volume. Then we design the architecture — select REST API methods, define field mapping. We implement event handlers on the site and configure webhooks in Bitrix24. Next, we set up the queue and retry mechanism. Testing includes conflict scenarios, rate limit exceedances, and failures. Finally, documentation and training.

Product Catalog Sync

If you use the Bitrix24 catalog (crm.product.*), it's important to sync it with the site catalog. Otherwise, deals will have "manual" items without references to nomenclature. The crm.deal.productrows.set method accepts an array of items with PRODUCT_ID — the product ID in the Bitrix24 catalog.

Strategy: when a product is created on the site via the OnAfterIBlockElementAdd event, automatically create/update the record in Bitrix24 using crm.product.add. XML_ID serves as external identifier for deduplication. This avoids nomenclature duplication.

What's Included and When It Pays Off

We provide a complete package: detailed documentation on integration architecture, configured REST API access and webhooks, manager training on the updated CRM, and 30-day post-launch support. All work is performed by certified specialists with over 10 years of experience.

The integration pays off within 1–2 months thanks to manual labor reduction. We'll assess your project in 2 hours — contact us for a consultation. Get a consultation on your project right now.

Learn more about the Bitrix24 REST API in the official documentation.