We often encounter situations where an online store on Bitrix loses up to 30% of orders due to incorrect delivery cost calculation or lack of pickup point selection. Integrating with the CDEK delivery service solves these problems but requires a deep understanding of API v2 and Bitrix architecture. Let's look at typical difficulties and our solution.
Why is CDEK integration with Bitrix complex?
CDEK uses OAuth 2.0 with a token that lives 3600 seconds. If the token is not cached, every request will fail with 401. Many modules from the Marketplace ignore caching, leading to errors under peak loads. Additionally, the API requires precise location mapping: the CDEK city code does not always match the Bitrix code. Without correct mapping, cost calculation returns zeros.
How we do it
We use the official SDK cdek-sdk2/cdek-sdk2 but do not limit ourselves to it. We build our own service class that inherits from \Bitrix\Sale\Delivery\Services\Base. We cache the token in \Bitrix\Main\Data\Cache for 3500 seconds—100 seconds margin from the lifetime. For city mapping, we use the request GET /v2/location/cities?city={name} and save the mapping in a highload block.
Cost calculation
private function calcPrice(\Bitrix\Sale\Shipment $shipment, string $toCode): float { $order = $shipment->getOrder(); $weight = max($shipment->getWeight(), 100); // minimum 100g $payload = [ 'type' => 1, // 1-internet store 'tariff_code' => 136, // 136-delivery to door 'from_location' => ['code' => $this->getOption('FROM_LOCATION_CODE')], 'to_location' => ['code' => $toCode], 'packages' => [ [ 'weight' => $weight, 'length' => $this->getOption('DEFAULT_LENGTH') ?: 20, 'width' => $this->getOption('DEFAULT_WIDTH') ?: 20, 'height' => $this->getOption('DEFAULT_HEIGHT') ?: 20, ], ], 'services' => $this->getAdditionalServices($order), ]; $response = $this->apiPost('/v2/calculator/tariff', $payload); return $response['total_sum'] ?? 0; } Tariff code 136 is “Parcel warehouse-door”. For delivery to a pickup point, 136 or 138 (“Parcel warehouse-warehouse”) is used. The current list of tariffs: GET /v2/calculator/tarifflist.
Creating a CDEK order
private function createCdekOrder(\Bitrix\Sale\Shipment $shipment): string { $order = $shipment->getOrder(); $propertyCollection = $order->getPropertyCollection(); $payload = [ 'type' => 1, 'number' => (string)$order->getId(), 'tariff_code' => 136, 'from_location' => $this->getFromLocation(), 'to_location' => $this->getToLocation($propertyCollection), 'recipient' => [ 'name' => $propertyCollection->getItemByOrderPropertyCode('FIO')?->getValue(), 'phones' => [['number' => $propertyCollection->getItemByOrderPropertyCode('PHONE')?->getValue()]], ], 'packages' => $this->buildPackages($shipment), 'comment' => 'Order #' . $order->getId(), ]; $response = $this->apiPost('/v2/orders', $payload); // Save CDEK order ID in Bitrix order properties $propertyCollection->getItemByOrderPropertyCode('CDEK_ORDER_UUID') ?->setValue($response['entity']['uuid']); $order->save(); return $response['entity']['uuid']; } Statuses and tracking
CDEK supports webhooks: configured in your personal account. When the order status changes, CDEK sends a POST to the specified URL. Status mapping:
| CDEK Status | Bitrix Order Status |
|---|---|
RECEIVED_AT_SHIPMENT_WAREHOUSE |
Accepted at warehouse |
READY_FOR_SHIPMENT_IN_TRANSIT_CITY |
Shipped |
ARRIVED_AT_DESTINATION_CITY |
Arrived in city |
DELIVERY |
Handed to courier |
DELIVERED |
Delivered |
NOT_DELIVERED |
Not delivered |
If no public IP, polling agent every 2 hours for active shipments.
Pickup points on the site
CDEK provides a JavaScript widget for selecting a pickup point on the map. The widget is called in the delivery component template and passes the selected pickup point code to a hidden form field. When creating an order, instead of to_location with an address, use delivery_point with the pickup point code.
window.open_cdek_map = function() { window.CDEKWidget.open({ defaultCity: 'Moscow', onChoose: function(type, tariff, address) { document.getElementById('cdek_pvz_code').value = address.code; document.getElementById('cdek_pvz_name').value = address.name; } }); }; Waybill and barcode
After creating an order in CDEK, a waybill can be generated: POST /v2/print/orders with the order UUID. The response contains a link to download the PDF. We implement a button in the Bitrix order admin panel: the manager clicks “Print CDEK waybill”—a PDF opens.
What is included in the work
- Analysis of the current delivery scheme and settings of methods in Bitrix.
- Registering an application in the CDEK personal account, obtaining
client_idandclient_secret. - Development of a custom delivery service with token caching support.
- Location mapping (Bitrix ↔ CDEK) via the cities API.
- Integration of cost calculation, order creation, and tracking (webhooks or polling).
- Embedding the pickup point widget on the checkout page.
- Waybill print button in the admin panel.
- Operational documentation and training for your developer.
- One month of post-launch support.
How to ensure integration stability?
Our engineers have over 10 years of experience with Bitrix and hundreds of integrations with payment and logistics services. We use tagged caching, event-driven architecture, and agents for background tasks. Every project undergoes code review and load testing. The integration comes with a warranty—if issues arise, we fix them within 24 hours.
Automation via API is 3 times faster than manual data entry and reduces errors by 80%. CDEK API documentation confirms that proper token caching increases stability by 99%.
Example of integration with the pickup point widget
The widget is called when the pickup point selection button is clicked. The response code is embedded into a hidden order field. The selected pickup point and delivery status are displayed in the admin panel.
What to do if the API returns an error?
Common errors: 401 (unauthorized) — refresh the token; 400 (invalid data) — check city mapping; 403 (no permissions) — ensure the OAuth application has the required scopes. Our team provides a detailed log of each request for quick diagnostics.
Work process
- Analysis — clarify requirements (tariffs, need for pickup points, order volume).
- Design — define service structure, mapping, caching.
- Implementation — write code, configure webhooks, widget.
- Testing — test on test orders, simulate errors.
- Deploy — move to production server, set up monitoring.
Estimated timelines
| Scope | Time |
|---|---|
| Cost calculation + order creation | 4–5 days |
| + Tracking (webhooks or polling) | +2 days |
| + Pickup point widget on site | +2 days |
| + Waybill in admin panel | +1 day |
| Full cycle | up to 10 days |
The cost is calculated individually. To get an accurate estimate, contact us: send a description of your store and the required functionality. We will analyze it for free and propose a solution. Order integration today and start saving on delivery.

