Developing Bitrix24 Integration with Logistics Systems

When a manager closes a deal in CRM, and logistics staff manually transfer data to TMS, up to 30 minutes are lost per request — amounting to hundreds of hours of operational time per month.

Manual entry errors (wrong address, incorrect weight) lead to re-sorting and repeat deliveries, producing extra expenses. We develop integration between Bitrix24 and your logistics system — from request creation to tracking and notifications. A request is automatically generated upon a deal stage change, recipient data is pulled from the contact, and items from the deal. Processing time drops from hours to seconds, and errors to zero. Turnkey, with stable performance guarantees and up to 60% savings in the delivery department's time. Our delivery automation solution covers all key processes: from request to return.

What logistics systems and APIs do we integrate?

1C:TMS Logistics. 1C HTTP services, data format — JSON or XML. Main operations: creating a transport request, getting status, attaching documents.

MySklad. REST API with OAuth 2.0. Rich documentation, sandbox. Supports order management, shipments, stock, returns.

CDEK API v2. REST API, JWT authentication. Cost calculation, order creation, tracking, pickup point list.

Yandex.Delivery / DPD / Boxberry / PEK. Each has its own REST API, differing in data structure and authentication mechanisms. For universal integration with multiple carriers, we use the adapter pattern: a single interface inside the application, with a separate implementation for each carrier.

WMS systems (Manhattan, SAP Extended Warehouse Management, 1C:WMS). Typically SOAP or proprietary API. Integration is more complex due to legacy protocols.

According to CDEK API documentation, version v2 handles up to 100 requests per minute with an average response time of 1.5 seconds.

Why is asynchronous processing critical for integration?

Logistics APIs are unstable: rate limits, timeouts, unavailability. Therefore, we build an async queue (Redis + Bitrix built-in agents). The webhook from Bitrix24 is accepted instantly, while the logistics API call and status updates are executed asynchronously. This is 2-3 times more reliable than a synchronous approach and does not block managers' work. For example, with a 30-second timeout, a synchronous request would block the interface, while an asynchronous approach simply retries after 30 seconds.

Integration scenarios

Deal → delivery request. A deal in Bitrix24 moves to the "Sent for shipment" stage — a webhook fires, the adapter creates a request in the logistics system. The deal card gets the request ID (UF_LOGISTICS_ORDER_ID) and tracking number.

Delivery statuses in CRM. The logistics system sends a webhook on status change: "Accepted at warehouse", "In transit", "Delivered", "Return". The adapter updates the deal stage via crm.deal.update and adds a timeline comment via crm.timeline.comment.add.

Delivery cost calculation. At order creation (in a deal or online store) — request to the carrier API for cost calculation by weight, dimensions, and address. Result saved in deal or invoice fields.

Pickup point selection. For integrations with CDEK, Boxberry, Russian Post — a pickup point chooser on a map inside the deal card. Implemented as a Bitrix24 embedded application with a map (Leaflet + pickup point data from the carrier's API).

Returns. The customer initiates a return — a smart process "Return" is created in CRM, triggering the procedure in the logistics system: pick-up from customer, warehouse acceptance, item inspection status.

Adapter architecture

We build a PHP application that:

1. Listens to Bitrix24 webhooks (deal stage change event)
2. Maps deal data to the logistics system format
3. Calls the logistics API
4. Writes the response back to Bitrix24

Bitrix24 (stage change webhook) ↓ Adapter (validation, data transformation) ↓ Logistics system API ↓ (async — via callback or polling) Adapter (status processing) ↓ Bitrix24 REST API (crm.deal.update, crm.timeline.comment.add) 

Example webhook handler in PHP:

function handleBitrixWebhook($event) { $dealId = $event['data']['FIELDS']['ID']; $deal = CRest::call('crm.deal.get', ['id' => $dealId]); $address = $deal['UF_DELIVERY_ADDRESS']; $phone = $deal['UF_DELIVERY_PHONE']; // Call CDEK API $cdek = new CdekApiClient(); $order = $cdek->createOrder([ 'recipient' => ['name' => $deal['CONTACT_NAME'], 'phone' => $phone], 'address' => $address, 'items' => $deal['PRODUCTS'] ]); CRest::call('crm.deal.update', [ 'id' => $dealId, 'fields' => ['UF_CDEK_ORDER_ID' => $order['uuid']] ]); } 

Field mapping

Typical set of fields to pass to the logistics system:

Weight and dimensions are a separate challenge. In Bitrix24, they are stored in the product card (catalog), but in a CRM deal they are taken from crm.product.list by PRODUCT_ID. If integration with a warehouse or 1C is not set up, weight characteristics may be missing — a fallback is needed (default values by product category or manual input). For exchange with 1C via CommerceML, we additionally configure nomenclature synchronization.

Tracking and customer notifications

After receiving the tracking number, we build a notification chain. A Bitrix24 robot sends an SMS or email to the customer (via integration with a mailing service): "Your order has been handed over for delivery, tracking number: XXX". On each status change — similarly. This reduces call center load by 4 times and increases customer satisfaction. The status check agent runs every 15 minutes, and notifications are sent within 5 minutes of a status change.

For automatic delivery status retrieval, we use two approaches:

• Webhook from carrier — the carrier notifies on status change. Best option, but not supported by all.
• Polling — a Bitrix agent queries the status every N minutes by tracking number. Works with any carrier, creates API load.

What to do when the logistics API fails?

Logistics APIs are unstable and have specific limitations:

• Rate limiting — we pause between requests, cache reference data (pickup point list, tariffs). For example, CDEK limits 100 requests per minute.
• Address errors — the carrier cannot determine delivery zone by address. A UI for manual correction with manager notification is needed.
• Blocked requests — if logistics blocks a request (incorrect data), the manager must see this in CRM, not learn from the customer.

For exception handling, we use a queue with retries (exponential backoff up to 5 times: 1, 2, 4, 8, 16 minutes) and CRM notifications. If after all retries the API is unavailable, a task is created for the operator with full error context.

What's included in the work

• Analysis of your logistics system APIs and scenario selection
• Adapter development with async queue and retries
• Configuration of deal fields, smart processes, and Bitrix24 business processes (Bizproc) for automatic logistics
• Creation of a pickup point selection widget (if required)
• Automatic customer notifications via SMS and email based on statuses
• Testing on real requests in a test environment
• Technical documentation and employee training
• 6-month warranty on integration after delivery

Development stages

A completed integration reduces the time from deal creation to delivery request from hours to seconds — and eliminates manual data entry errors. Order integration — get a working solution with a 6-month warranty. Contact us for a project assessment: we'll select the optimal turnkey solution.