Even a single delivery to a village becomes a problem: courier services don't go there, and Belpochta remains the only operator covering all of Belarus. Without integration, managers manually enter data on the post's website—errors, delays, lost statuses. Customers are unhappy, and you waste time. Manual parcel creation takes 10–15 minutes, and with 50 orders per day that's hours of useless work. Errors in entering the index or weight lead to returns and re-sends—up to 20% of orders require correction. Our engineers with 10+ years of experience integrated Belpochta with dozens of stores on 1C-Bitrix, processing over 100,000 parcels. The solution covers the entire cycle: from cost calculation to label printing and tracking.
How to integrate Belpochta API with a Bitrix catalog?
Belpochta provides SOAP and REST APIs. We recommend the REST version: https://api.belpost.by/api/v1. Authorization via a token in the header Authorization: Token <token>. The token is issued after signing a contract with Belpochta and connecting the "Electronic Delivery" service.
Main API methods:
| Method |
Purpose |
Frequency of use |
POST /parcel/calculate |
Calculate shipping cost |
every time the cart changes |
POST /parcel/create |
Create a parcel |
when placing an order |
GET /parcel/{id} |
Parcel status |
by agents every 6 hours |
GET /parcel/{id}/label |
Get label in PDF |
when printing from admin panel |
Cost calculation is implemented via a custom transport. We register a handler on the event OnSaleDeliveryHandlersBuildList and add a class BelposhtaHandler. In the order properties, we must add the recipient's index (6 digits) — without it, calculation is impossible.
class BelposhtaHandler extends \Bitrix\Sale\Delivery\Services\Base
{
protected function calculateConcrete(
\Bitrix\Sale\Shipment $shipment
): \Bitrix\Sale\Delivery\CalculationResult {
$result = new \Bitrix\Sale\Delivery\CalculationResult();
$response = $this->apiPost('/parcel/calculate', [
'from_region' => $this->getOption('SENDER_REGION_CODE'),
'to_index' => $this->getRecipientIndex($shipment),
'weight' => max((int)($shipment->getWeight()), 50), // grams, min 50g
'cost' => round($shipment->getOrder()->getPrice()),
'payment' => 'prepaid', // or cod
]);
if (!empty($response['amount'])) {
$result->setDeliveryPrice((float)$response['amount']);
$days = $response['delivery_days'] ?? '3–7';
$result->setPeriodDescription("{$days} days");
}
return $result;
}
private function getRecipientIndex(\Bitrix\Sale\Shipment $shipment): string
{
$props = $shipment->getOrder()->getPropertyCollection();
return (string)($props->getItemByOrderPropertyCode('ZIP')?->getValue() ?? '');
}
}
The recipient's index is a mandatory order property. We add it via \Bitrix\Sale\Property with code ZIP and bind it to the delivery service. When Belpochta is selected, the property becomes required.
How to create a parcel and print labels?
After placing an order, it is necessary to create a parcel. We send a POST request with full sender and recipient data. In response, we get a parcel_id, which we save in the order (for example, in a UF field).
public function createParcel(\Bitrix\Sale\Shipment $shipment): string
{
$order = $shipment->getOrder();
$props = $order->getPropertyCollection();
$payload = [
'sender' => [
'name' => $this->getOption('SENDER_NAME'),
'address' => $this->getOption('SENDER_ADDRESS'),
'phone' => $this->getOption('SENDER_PHONE'),
],
'recipient' => [
'name' => $props->getItemByOrderPropertyCode('FIO')?->getValue(),
'phone' => $props->getItemByOrderPropertyCode('PHONE')?->getValue(),
'index' => $props->getItemByOrderPropertyCode('ZIP')?->getValue(),
'address' => $props->getItemByOrderPropertyCode('ADDRESS')?->getValue(),
],
'parcel' => [
'weight' => max((int)$shipment->getWeight(), 50),
'cost' => round($order->getPrice()),
'contents' => 'Goods',
],
'payment' => $this->getPaymentType($order), // prepaid or cod
'cod_sum' => $this->getCodSum($order),
];
$response = $this->apiPost('/parcel/create', $payload);
return (string)($response['parcel_id'] ?? '');
}
The label is returned in PDF format. We add a "Print label" button in the administrative section of the order. When clicked, an agent is called that receives the PDF via GET /parcel/{id}/label and sends it to print. Tracking is updated by agents every 6 hours—this is sufficient because Belpochta updates statuses once a day. For faster updates, you can set up a webhook from Belpochta, but they do not yet provide push notifications.
When is Belpochta the optimal choice?
Belpochta is 2–3 times cheaper than courier services to regions, especially for deliveries to villages and townships. The API allows automation of the entire cycle: from calculation to label printing. For online stores targeting all of Belarus, this is a mandatory channel.
Features:
- Minimum weight — 50 g. Items smaller than that are processed as a "small packet" under a different tariff—the module automatically selects the tariff.
- International delivery: Belpochta is a member of the UPU, shipping to CIS countries and far abroad. Customs declarations CN22/CN23 via a separate API method. The integration supports filling out declarations based on catalog item positions.
- Timelines: within Belarus 3–7 business days, to remote areas up to 10 days. Actual timelines depend on branch workload.
- Cash on delivery is supported, transfer once a week. The cash-on-delivery amount (cod_sum) is automatically calculated as the order cost plus the postal fee.
Integration reduces labor costs for order processing by up to 95%. Manual entry errors are eliminated—addresses and weights are taken directly from the order. This is especially important for online stores with a large assortment and high seasonality. Savings on processing one order amount to up to 8 minutes, which for 100 orders per month gives more than 13 hours of saved time.
What is included in the work
- Analytics: audit current exchange, identify integration points (calculation, creation, printing, tracking).
- Design: develop handler scheme, agents, HL-blocks (if additional logic is needed).
- Development: implement transport, synchronization agents, printing interface. Calculation request caching — tagged, tied to the cart.
- Testing: on Belpochta's test environment (sandbox) — check all scenarios including API errors and timeouts.
- Launch: install module on production server, configure agents, train staff. Documentation for operation and disaster recovery.
Timeline
| Component |
Duration |
| Cost calculation + parcel creation |
3–5 days |
| + Label printing + tracking |
+2 days |
| + International shipments |
+2 days |
| Full functionality (all options) |
5–9 days |
Timelines vary depending on catalog complexity and integration requirements with 1C. For example, if trade offers and infoblocks v2.0 are already configured, integration is faster. For online stores working with 1C via CommerceML, we set up the transfer of delivery statuses back to 1C.
We will assess your project for free — contact us for a consultation. Order integration — it will pay off within the first hundred shipments thanks to time savings and reduced returns. Get a ready solution in 5–9 days.
Delivery integration: from disparate APIs to a unified calculator in 5 days
A buyer abandons the cart at the shipping stage — they don't see a quote or see an obviously incorrect price. Each such case loses conversion. Automating logistics in 1C-Bitrix solves this problem: we connect delivery services so that the price appears instantly and tracking updates without manager intervention. Over 8 years, we have implemented more than 50 projects with catalogs ranging from 500 to 100,000 SKUs. Average time to connect one carrier is 4 days.
How to accelerate the connection of delivery services to 1C-Bitrix?
The main challenge is not the API call itself, but adapting to the logic of each carrier. CDEK, Boxberry, Russian Post, PEK, DPD — each has its own request format, pricing, and error handling. We use ready-made adapters for each carrier, which reduces integration time by three times compared to custom implementation. Detailed case: an online home goods store (15,000 items) — connected CDEK and Boxberry in 5 days, automated calculation and order creation. Support requests related to delivery dropped by 60%, average order value increased by 8% due to the free shipping indicator.
Why is each carrier's API a separate challenge?
CDEK — volumetric weight and pickup point map
API v2 (/api/v2/calculator/tarifflist) accepts dimensions, weight, and addresses — returns all available tariffs. Pitfalls: volumetric weight is calculated using the formula (L × W × H) / 5000. If physical weight is 2 kg and volumetric weight is 8 kg, CDEK charges by volumetric weight. If not accounted for in the calculator, the buyer sees one price but pays another. The pickup point map is loaded via /deliverypoints. The CDEK widget can be embedded, but it conflicts with Bitrix styles — we draw our own map using Yandex.Maps. Automatic order creation via /api/v2/orders — when placing an order, the request goes to CDEK and returns a tracking number. Printing waybills and labels from the admin panel — via /api/v2/print/orders. Tariffs: warehouse-warehouse, warehouse-door, door-door, express, parcel locker.
Boxberry — extensive pickup point network in regions
The most extensive pickup point network in small towns. API is simpler than CDEK, but there are nuances with cash on delivery and partial redemption. Pickup point map with filters: fitting, card payment, weekend operation. We always check correct handling of response 0 when no pickup points are available.
Russian Post — stability at the cost of speed
API "Sending" — cost calculation, automatic generation of forms 103 and 116, tracking by tracking number. Tariffs: parcel, printed matter, EMS. International shipments. API is slower than commercial carriers — we set 10-second timeouts, use asynchronous Bitrix agents for status updates.
PEK — heavy loads and groupage
When you need to ship a sofa or equipment. Calculation of groupage cargo, insurance, crate. Delivery to terminal and door-to-door. PEK terminal indices are loaded into an infoblock for auto-completion.
DPD — express delivery with time slots
DPD across Russia and abroad. Delivery within a selected time interval, return of signed documents. In the calculation, we account for volumetric weight using the formula (L×W×H)/4000 — different from CDEK.
Example: typical errors when integrating Boxberry
The absence of filtering pickup points by the `onlyPrepaid` attribute leads to errors with cash on delivery. Ignoring the `partialReturn` parameter breaks partial redemption. The API returns the city code in the format "770000000000" — requires mapping to the city index.
How to combine different carriers in a single calculator?
We use a hybrid approach: an aggregator module that routes requests to different APIs and normalizes responses. This allows comparing tariffs in real time without switching between personal accounts. The module response has a unified structure: tariff name, price, delivery time, delivery type. Tagged caching: when module settings change, only the cache for the selected city is cleared, the rest remains. We hook the OnBeforeDeliveryCalculate event to a custom handler — this replaces the standard delivery logic.
Cost calculation: what pitfalls are encountered?
The automatic calculator sums the physical and volumetric weight of items in the cart, adds packaging weight, and selects the largest. Sounds simple, but:
- Dimensions must be filled for each item. No dimensions — no calculation. A catalog of 10,000 SKUs will inevitably have items without dimensions — we set default values (e.g., 0.1×0.1×0.1 m) and warn the manager via a mail event.
- Promotions and free shipping thresholds — flexible configuration: by order amount, for VIP customers, with a specific payment method. Implemented via custom cart properties.
- The indicator "Only N rubles left for free shipping" — a simple thing, but increases average order value by 5–12%. Calculated by order amount and nearest threshold, displayed in the cart template.
How to automate tracking, pickup, and courier delivery?
Tracking. Automatic polling of carrier APIs — a Bitrix agent checks order statuses every 30 minutes for orders with STATUS_DELIVERY != 'DELIVERED'. Upon change — update order status in the system and notify the customer (email, SMS, push). Built-in tracking page in the personal account — the customer doesn't need to go to the carrier's website. Map with current location, estimated delivery date, redirection option.
Pickup. Own pickup points on the map: addresses, schedule, contacts. Search for the nearest by customer address. Real-time availability check, reservation until a specific time. QR code for quick pickup and SMS about readiness.
Courier delivery. Delivery zones with different costs. 2-hour slots, courier schedule management, order limit per slot. Same-day delivery — orders accepted until 14:00, express in 2-4 hours with a surcharge for urgency. Integration with navigation for route optimization.
Multi-warehouse. Multiple warehouses with addresses and service zones. Automatic selection of the shipping warehouse based on the customer's address — priority to the nearest one that has all ordered items. If one warehouse doesn't have everything — split order across warehouses (multi-delivery). Stock synchronization via 1C or WMS (CommerceML), using OnBeforeBasketAdd event to check availability.
Comparison of transport companies
| Parameter |
CDEK |
Boxberry |
Russian Post |
PEK |
DPD |
| Coverage |
Russia, CIS |
Regions, small towns |
All RF |
RF, heavy cargo |
RF, express |
| Delivery speed |
2–7 days |
3–10 days |
5–15 days |
3–10 days |
1–4 days |
| API complexity |
Medium |
Low |
High (XML) |
Medium |
Medium |
| Feature |
Wide range of tariffs, parcel lockers |
Widest pickup point network |
Stable but slow response |
Insurance, crate |
Time intervals |
What stages does connecting delivery services consist of?
-
Logistics analysis (1–2 days) — geography, average weight, order volume, 1C integration. We recommend a combination of carriers.
-
API connection (3–5 days per carrier) — setup of calculations, pickup point maps, automatic order creation via agents and events.
-
Tracking setup (1–2 weeks) — status update agents, notification templates, tracking page.
-
Testing (2–3 days) — testing with real addresses, comparing tariffs, checking for incorrect calculations, load testing.
-
Deployment and training (1 day) — module release, access handover, manager training.
-
Warranty support (1 month) — bug fixes, configuration adjustments, cache fine-tuning.
Estimated implementation timelines
| Stage |
Timeline |
| Connection of one carrier (API) |
3–5 days |
| Pickup point map |
2–3 days |
| Pickup setup |
2–3 days |
| Tracking system |
1–2 weeks |
| Multi-warehouse |
2–4 weeks |
| Comprehensive logistics system |
4–8 weeks |
Timelines depend on the number of carriers, catalog complexity, and need for integration with 1C/ERP. Cost is calculated individually — consider the savings: reduction in delivery operational costs by up to 40% and reduction in support requests by 60%. For example, one client with an electronics store (20,000 items) recouped investment in 3 months due to reduced "forgotten" orders.
Ready to accelerate your online store's logistics? Contact us — we'll help select the optimal carrier combination for your assortment and budget. Request a consultation, and we'll prepare a proposal within 1 business day.