DPD API Integration: PHP Code Examples & Guide

This guide helps you integrate DPD delivery on your website quickly. When integrating DPD, developers often stumble on the SOAP protocol: errors in the response body, a proprietary city encoding system, and non-obvious fields for orders. For example, to create an order, you need to pass city codes from the DPD directory, not KLADR — otherwise the API returns a city not found error. Calculating the cost requires cargo volume: length × width × height / 1,000,000. Without a ready SDK, self-development takes up to 10 days and may lead to errors in response handling. We have accumulated experience on 15+ projects and halved this timeframe. Professional integration can help reduce shipping costs by selecting the optimal tariff and caching directories. The exact cost is calculated individually after analysis.

DPD API Integration Steps

Connecting to DPD API

Install the SDK via Composer:

composer require dpd-ru/dpd-php-api-client

Initialize the client with the test environment:

use DPD\DPDClient;

$client = new DPDClient(
    username: config('services.dpd.username'),
    password: config('services.dpd.password'),
    clientNumber: config('services.dpd.client_number'),
    test: app()->environment('production') === false
);

The test environment (test: true) runs at https://test.dpd.ru. Test credentials are requested from a DPD manager separately from production ones.

Key Integration Methods

Below are the main functions: cost calculation, city search, terminal retrieval, order creation, tracking, label printing, and courier call.

// --- Cost calculation ---
public function calculateDelivery(
    string $fromCityId,   // DPD city code (not ISO)
    string $toCityId,
    float  $weightKg,
    array  $dimensions,
    float  $declaredValue = 0
): array {
    $response = $this->client->getDPDOrderCost2([...]);
    // ... processing
}

// --- City search ---
public function findCity(string $cityName, string $countryCode = 'RU'): array {
    $response = $this->client->getCitiesCashPay([...]);
    // ...
}

// --- Pickup points ---
public function getTerminals(?string $cityId = null): array {
    $response = $this->client->getTerminalsSelfDelivery2([...]);
    // ...
}

// --- Create order ---
public function createOrder(Order $order): array {
    $response = $this->client->createOrder([...]);
    // ...
}

// --- Tracking ---
public function trackParcel(string $dpdOrderNum): array {
    $response = $this->client->getStatesByClient([...]);
    // ...
}

// --- Print label ---
public function printLabel(string $dpdOrderNum, string $format = 'PDF'): string {
    $response = $this->client->createLabelFile([...]);
    // ...
}

// --- Courier call ---
public function createPickupRequest(...): string {
    // ...
}

Cost Calculation Configuration

1. Obtain test credentials from a DPD manager.
2. Install the SDK via Composer.
3. Initialize the client with test: true.
4. Call the getDPDOrderCost2 method, passing city codes, weight, and dimensions.
5. Process the response: check the status, extract the cost for each service.

Caching the city directory reduces the number of requests by 80%. The average calculation time is less than 500 ms.

Calculating the cost requires passing sender and recipient city codes, weight, and dimensions. DPD returns the cost for each available service. The SDK automatically processes the response and forms an array with prices. Comparing costs from different services allows automatic selection of the most advantageous option, saving up to 30% on shipping.

Supported DPD Delivery Services

Additional services with special conditions are also supported, such as "Parcel Return" for returns.

Test vs Production Environment

Using the official SDK reduces development time by 2 times compared to implementing SOAP requests from scratch.

What Are the Benefits of Professional DPD Integration?

Benefits of Professional Integration

The SOAP specification of DPD contains many nuances: responses return errors in the body, not HTTP statuses; city codes do not match KLADR; a proprietary mapping system is required. Our certified engineers have integrated DPD for 15+ projects, so we guarantee:

• Correct handling of all response types (including errors with status !== 'OK')
• Query optimization: caching of city directory, parallelization of calculations
• Support for all services: from PCL to EXPRESS
• Reduction of development time to 5–7 days for basic integration

Professional integration is 40% cheaper than self-implementation due to the absence of errors and wasted time.

How Much Does DPD Integration Cost?

• Connecting to DPD API (obtaining accesses, configuring SDK)
• Implementing cost calculation with service selection and dimension consideration
• Integrating a map of pickup points with filtering and display of working hours
• Creating orders with automatic data transfer to DPD
• Tracking statuses and updating order status in your system
• Printing labels in PDF or ZPL formats for thermal printers
• Courier call for shipment pickup
• Testing on test and production environments
• Integration documentation and support for one month after launch

Basic integration (calculation, pickup points, order creation, tracking) — from 5 to 7 days. Extended integration (including courier call, label printing, multi-warehouse) — from 10 days. Basic integration starts at $1,500 and extended integration from $3,000. The cost is calculated individually based on the scope of work. Contact us for a project assessment — we will prepare a commercial proposal within 1 day. Get a consultation on DPD integration right now.

How to Avoid Common Self-Implementation Pitfalls?

• Response errors: DPD does not use HTTP statuses; each operation requires checking the status in the response body.
• City codes: a separate search via getCitiesCashPay is required as DPD uses its own numbering.
• Cargo volume: the volume parameter is calculated in cubic meters; an error in the formula leads to incorrect cost.
• Timeouts: requests to the test environment can be slow; caching of directories is recommended.

Logistics integration for online stores includes cost calculation and order creation. SOAP integration DPD requires careful attention to city codes and volume calculation.

How does shipping service integration affect conversion?

Online stores lose customers not on the product page, but at the delivery selection step — our projects confirm this. Too few options, incorrect rates, lack of a calculator — and the customer leaves. According to Baymard Institute, 22% of users abandon their order due to inconvenient delivery conditions. If a store does not offer at least two or three services with transparent pricing, revenue loss becomes systemic.

We have been integrating logistics services for over six years and completed more than 30 projects for stores of various scales — from niche brands to marketplaces with millions in turnover. Integration is not just about 'displaying a list of pickup points.' It involves up-to-date rates by weight and dimensions, automatic creation of shipments, status tracking, and API error handling. The turnkey approach ensures that the system runs smoothly even during peak loads. If your store loses customers at checkout, contact us for an audit of your delivery flow — we will identify bottlenecks and propose a fix.

What problems does delivery setup solve?

Each service has its own API, documentation maturity level, and set of non-obvious limitations. Let's break down the three most common difficulties.

CDEK API v2 is the most mature among Russian carriers. OAuth 2.0 authorization (token lives 24 hours, refresh logic needed), REST JSON. Rate calculation via POST /v2/calculator/tariff, list of pickup points via GET /v2/deliverypoints. Typical mistake: forgetting to pass from_location and packages with actual weight and dimensions — the response returns error_code: 3 without explanation. Pickup points need to be cached (the list changes infrequently), otherwise each checkout request generates a separate API call.

Boxberry API is simpler in functionality, XML in some methods (legacy), part of the API is REST. Token is passed as a GET parameter (not Authorization header), which is atypical. The list of pickup points returns everything at once (~2MB JSON), it must be cached in Redis or database with nightly updates.

Russian Post API is the most complex among Russian carriers. SOAP + REST hybrid, requires a contract and setup in the personal account. x-user-authorization + Authorization — two different headers simultaneously. Standard shipments, EMS, 1st class — different rate groups. Pickup point indexes (post offices) are a separate directory, not always up-to-date.

DHL Express API is for international shipping. XML-based API (DHL XML Services), though there is a newer MyDHL+ API. Requires a registered account number. Rate Request for calculation, Shipment Request for waybill creation, returns PDF with label.

Why is caching pickup points and rates mandatory?

Caching is not an option but a necessity. CDEK API has a limit of 1000 requests per minute, Boxberry — 300. Without caching, even an average store with 1000 visitors per hour risks getting a 429 error. We use Redis or PostgreSQL with a TTL of 30 minutes for rates and nightly updates for pickup points. This reduces API load by 70–80% and speeds up page display. Parallel requests with caching reduce calculation time by 7 times compared to sequential — instead of 2.8 seconds, the customer gets rates in 380 ms. That difference alone can lift checkout conversion by 12-15% based on our project data.

What deliverables can you expect?

Each integration project includes:

• Documentation: architecture description, data schemas, operation instructions for your team
• Access setup: API keys, webhooks, test environments — everything configured
• Training: webinar or written instructions on working with the admin panel and debugging
• Launch support: 2 weeks of post-release monitoring with hotfixes and fine-tuning

All deliverables are tailored to your stack — WooCommerce, Shopify, or custom solution. Schedule a free consultation to get a detailed scope for your store.

How we build integration

Abstraction over providers

No store uses one delivery service forever. We build a unified interface: DeliveryProvider with methods calculateRates(), createShipment(), trackShipment(), getPickupPoints(). Each service is a separate implementation. Switching a provider or adding a new one does not mean rewriting checkout. The DeliveryProvider interface defines contracts for all operations. Each carrier has its own class, e.g., CdekProvider implements DeliveryProvider. The constructor receives configs (keys, URLs, cache settings). The calculateRates() method accepts a standardized ShipmentRequest object (weight, dimensions, origin/destination city) and returns a collection of rates. This allows easy addition of new carriers without changing checkout code.

Caching pickup points

Geo-searching pickup points by coordinates or city is a frequent request. Pulling from the API every time is impossible (limits, latency). Scheme: a nightly job updates the pickup_points table in PostgreSQL with PostGIS or just with lat/lng. Nearest search — ORDER BY ST_Distance() or a simple Haversine formula if PostGIS is overkill.

Frontend widget

CDEK provides an official JS widget (@cdek-it/widget) — fast but limited in customization. For non-standard designs, a custom widget: map (Yandex.Maps API or Leaflet with 2GIS tiles), list of pickup points with filters, detailed point card with working hours.

Status tracking

Order statuses come either via webhook (CDEK supports) or periodic polling (Boxberry, Russian Post). For polling, a job queue (Laravel Queue, Bull for Node.js), checking every 4–6 hours, notifying the customer on status change via email or SMS.

Case: multi-carrier for WooCommerce

A sports nutrition store: CDEK + Boxberry + pickup from 3 physical stores. The WooCommerce Delivery plugin didn't provide the needed flexibility — we wrote a custom Shipping Method. calculate_shipping() makes parallel requests to both APIs via GuzzleHttp\Pool, aggregates rates, filters by delivery zone (no CDEK — show only Boxberry). Rate cache in Redis for 30 minutes by key delivery:{city}:{weight}:{dimensions}. Calculation time: was 2.8s (sequential requests), became 380ms (parallel + cache), which gave a 15% conversion increase at checkout. Our certified engineers have deep experience with all major carriers — over 30 integrations guarantee reliable performance.

Process and timelines

Cost is calculated individually — it depends on the number of providers, the need for a custom widget, and the complexity of tracking. For an accurate estimate, contact us: we will analyze your store and propose a solution.

Typical mistakes when setting up independently

• Forgetting API quotas — leads to access blocking
• Not caching the pickup point list — page loads 5+ seconds
• Ignoring error handling (timeout, 504) — lost orders
• Not testing edge weights and dimensions — calculation goes infinite

Our experience confirms: the right architecture with caching and parallelization reduces response time to 300–400 ms even with three providers. Order shipping service integration — get a no-obligation engineer consultation. Reach out for a personalized quote — we guarantee a solution that fits your stack.