Delivery Tracking Module Development for 1C-Bitrix

A customer placed an order and is waiting for the package. If they have to go to the delivery service's website, copy the tracking number, and check the status each time — that's a poor experience that reduces loyalty and increases support load. Automating tracking solves this: statuses update automatically, the user sees them in their personal account and receives notifications. Such a solution saves up to 80% of time spent on manual checking — this is the result of our projects for online stores with 500+ orders per day. Order the development of a module for your store — get a consultation within a day.

Delivery Automation: Why It Is Necessary

Manual status updates are a source of errors and delays. Managers spend hours copying tracking numbers, while customers get anxious due to lack of information. Automation removes this burden: the module itself polls delivery service APIs, records history, and notifies the buyer. According to our measurements, repeat purchase conversion increases by 15–25% after implementing tracking in the personal account. Automated tracking is 3 times more reliable than manual checking. Automation is 3–5 times faster in reacting to changes compared to manual tracking.

Technical Implementation

Data Sources

The tracking number appears in the order after it is transferred to the delivery service. In Bitrix, it is stored in the TRACKING_NUMBER field of the b_sale_order_delivery table or in a custom order property. Delivery modules (DPD, CDEK, Boxberry, Russian Post) store the tracking number differently — this is taken into account when implementing adapters.

Status Update

A cron job runs every 30 minutes by default; the interval is configurable based on load. The script selects orders in statuses that imply active delivery (DELIVERY, DELIVERING), obtains current statuses from the provider for each, compares with the last recorded status in b_tracking_status. If the status changed, a new record is written and the NOTIFIED flag is set to 0. The next pass iterates over records with NOTIFIED = 0 and sends notifications. This ensures the customer learns about the package movement within an hour of the event.

Delivery Service Support

The module can connect any service via a unified adapter interface. Adapters are developed for the specific REST or SOAP API of the provider. This allows using multiple services simultaneously on one site and quickly adding new ones without changing the module core. For example, in projects with 3+ providers, we use a common DeliveryProviderInterface.

Module Architecture

local/modules/vendor.tracking/ ├── lib/ │ ├── Provider/ # Adapters for delivery service APIs │ │ ├── CdekProvider.php │ │ ├── DpdProvider.php │ │ └── RussianPostProvider.php │ ├── TrackingService.php # Orchestrator │ └── StatusMapper.php # Status normalization ├── install/ │ └── db/install.sql └── cron/ └── update_statuses.php 

Table b_tracking_status — history of statuses for each order:

API Integration

Each provider implements the interface:

interface DeliveryProviderInterface { public function getStatuses(string $trackingNumber): array; public function getProviderCode(): string; } 

CDEK uses REST API v2. Token via POST /v2/oauth/token, statuses via GET /v2/orders?cdek_number={number}. Response contains a statuses array with fields code, name, date_time, city. More about CDEK API — on Wikipedia.

Russian Post provides a SOAP service at https://tracking.russianpost.ru/rtm34. The getOperationHistory method returns XML with operations for the shipment. Parsing via SoapClient or direct XML parsing with SimpleXMLElement. The SOAP protocol is described in Microsoft documentation.

DPD — REST API, tracking via GET /api/tracing/order/{trackingNumber}.

Status Normalization

Each provider has its own status codes. StatusMapper maps them to a unified set:

This allows building a unified tracking interface regardless of the delivery service. Status DELIVERED is displayed with a green icon, FAILED with a red icon and an offer to contact support.

Typical Problems and Their Solutions

Race conditions when writing statuses — when multiple data packets arrive simultaneously, duplicates can occur. We use INSERT ... ON DUPLICATE KEY UPDATE with a unique index on ORDER_ID + EVENT_TIME. API rate limits — CDEK has a limit of 5 requests per second, Russian Post — 10. The module has a built-in queue with timeout and retry. Duplicate notifications — solved via the NOTIFIED flag, which is checked before sending.