Integration of 1C-Bitrix with the ApiShip delivery aggregator
A Bitrix store with 500 orders per month spends up to 40 hours maintaining direct integrations with CDEK, Boxberry, and Russian Post. Any change to a service's API is an emergency: code edits, testing, deployment. ApiShip centralizes everything: a single API for 30+ carriers, unified calculation and tracking.
We implemented such a solution for a client in the DIY segment — after integration, delivery support time dropped from 20 hours per week to 2, and monthly savings amounted to cost calculated after audit.
Why choose the ApiShip aggregator instead of direct integrations?
A direct integration with each service means separate modules with different credentials, different request and response schemas, and the need to monitor API changes for each carrier and update the code.
ApiShip unifies everything: single authorization (Bearer token), cost calculation across all carriers in one request, shipment creation via a single endpoint, tracking in a unified format.
The flip side: the aggregator adds a layer — sometimes there is a 1–2 day delay when a carrier's API is updated. For stores with non-standard requirements for a specific carrier, a direct integration may be more precise. But in 90% of cases ApiShip is the optimal choice: we guarantee stability and timely support.
ApiShip API: main endpoints
Base URL: https://api.apiship.ru/v2. Authorization: Bearer token. Test environment: https://api.test.apiship.ru/v2. For more details, see the ApiShip API documentation.
| Method | URL | Description |
|---|---|---|
| POST | /calculator | Cost calculation across active carriers |
| POST | /orders | Creating a delivery request |
| GET | /orders/{id} | Getting the request status |
| GET | /points | List of pickup points by filter (city, carrier) |
| GET | /deliveries | List of connected carriers |
| DELETE | /orders/{id} | Canceling a request |
How do we implement the ApiShip integration in Bitrix?
A single module covers all services. Architectural choice: either a single \Bitrix\Sale\Delivery\Services\Base class with a "carrier" parameter, or several instances of one class for different carriers (courier, pickup point, etc.). The second approach is more convenient for the customer: they see separate delivery methods.
Parameters in b_sale_delivery_service_params:
APISHIP_API_KEY— key from the ApiShip account;PROVIDER_KEY— carrier code (cdek, boxberry, russian_post, etc.);FROM_POINT_ID— ID of the dispatch point (warehouse in the ApiShip system);DELIVERY_TYPE—door(courier) orpoint(pickup point).
Cost calculation
$calcRequest = [
'fromPoint' => ['id' => $fromPointId],
'toPoint' => [
'address' => $deliveryAddress,
'cityId' => $apishipCityId,
],
'parameters' => [
'weight' => $weightGram,
'length' => $lengthCm,
'width' => $widthCm,
'height' => $heightCm,
'declaredValue' => $declaredValue,
],
'deliveryType' => $deliveryType,
'providers' => [$providerKey], // empty array = all carriers
];
$results = $httpClient->post('/v2/calculator', $calcRequest); // $results — array of options with rates and timeframes for each carrier
"}
If providers is an empty array, ApiShip will return a calculation across all active carriers. This allows you to implement a delivery method comparison block with rates on the site.
Retrieving and storing pickup points
Pickup points in ApiShip are requested by filters:
GET /points?cityId={id}&providerKey={key}&type=pickup_point
We load them once a day via an agent for active carriers. We store them in an HL block "Pickup points" with fields: providerKey, pointId, name, address, lat, lng, workingHours, maxWeight. On the map we display everything aggregated — the customer selects any pickup point of any carrier.
When a pickup point is selected, we save to b_sale_order_props: APISHIP_PROVIDER_KEY and APISHIP_POINT_ID.
Creating a request
$orderPayload = [
'providerKey' => $providerKey,
'senderPointId' => $fromPointId,
'deliveryType' => $deliveryType,
'toPoint' => [
'id' => $pvzId, // if pickup point
'address' => $address, // if courier
],
'recipient' => [
'name' => $name,
'phone' => $phone
],
'parameters' => $parameters,
'orderNumber' => 'SHOP-' . $bitrixOrderId,
'declaredValue' => $declaredValue,
'cashOnDelivery' => $codAmount,
'places' => $places,
];
Response: orderId in the ApiShip system and the carrier's trackingNumber. We save both to b_sale_order_props.
Tracking and statuses
More about setting up webhooks
Webhooks: ApiShip sends a POST when the status changes. We register the URL in the account. Statuses are unified for all carriers — a single mapping works for everyone.
What is included in the work
When ordering a turnkey integration, we provide:
- analysis of the current delivery scheme and recommendations;
- development of a module tailored to your business processes;
- setup of cost calculation, pickup point selection, and request creation;
- integration with tracking and webhooks;
- API documentation and an instruction manual for operators;
- a 3-month guarantee of uninterrupted operation.
Our experience and guarantees
We have been developing on 1C-Bitrix and Bitrix24 for 5+ years. We have 10+ successful delivery service integration projects under our belt, including with ApiShip, direct carrier APIs, and custom solutions. We provide a guarantee on all work — if something goes wrong, we will fix it as a priority. Contact us to get a consultation and an estimate for your project.
Approximate timelines
| Scope | Composition | Timeline |
|---|---|---|
| One carrier via ApiShip | Calculation + requests + tracking | 3–4 days |
| Multiple carriers | + Selection logic + multiple instances | 5–6 days |
| + Pickup point map | HL block + widget | +2–3 days |
| + Tariff comparison | JS block at checkout | +2 days |
The budget is calculated individually — it depends on the scope and complexity. Send us a description of your delivery scheme — we will estimate the project and prepare a commercial proposal. Contact us to discuss the details.







