Skip to main content
Talk to an expert
DPD logo

DPD integration for ecommerce fulfilment

Ship parcels to DPD, track events to customer accounts iWeb integrates DPD into your fulfilment flow so that orders move from pick-pack to despatch with automated label generation, tracking synchronisation and exception visibility. Works with Adobe Commerce, Magento Open Source, Shopify Plus, BigCommerce and other storefronts.

Also searched as: shipping connector, warehouse integration, fulfilment plugin, app.

DPDiWeb integration layeryour storefront
Talk to an expertSee the estate map ↓
Works with - Adobe Commerce · Magento Open Source · Shopify Plus · BigCommerce · Other storefronts
On this pageGet a brief reviewed
01 · What you get

What a DPD integration gives you.

Faster pick-pack-label cycle

Shoppers receive tracking information within minutes of despatch, not hours. Your warehouse team prints labels in sequence without manual intervention or data re-entry.

Accurate inventory and invoice timing

Stock is decremented and invoices are generated only when DPD confirms pickup, aligning financial records with physical despatch and reducing reconciliation friction with ERP.

Visibility and exception handling

Address failures, oversells and tracking gaps are surfaced in a named queue before they cause customer complaints or logistics failures. Fulfilment teams know what to fix and when.

Rules and carrier choices owned in one place

Service level, delivery window and special instructions are defined in your OMS or commerce configuration, not hardcoded in the integration. Changing rules does not require a deployment.

Returns and reverse logistics tracked end-to-end

RMA labels are generated at point-of-return and returned parcels are tracked through DPD's network. Stock and financials see the return event when the parcel is received back at your warehouse.

02 · When it's worth it

Where a DPD integration earns its place.

If two or more of these are true, the integration usually pays for itself quickly.

Next-day and express parcel delivery for domestic and cross-border orders
Automated label generation and thermal printer output at pick-pack stations
Real-time tracking events pushed to customer accounts and order status feeds
Carrier service selection rules based on delivery postcode, order weight and deadline
Returns label generation and reverse logistics tracking via DPD parcel return service
03 · The limits

Where off-the-shelf connectors fall short.

Vendor connectors are fine for simple cases. Here's where the real ones need more.

Carrier service rules live outside DPD

DPD does not govern which service level (Next Day, Express, etc.) applies to each shipment. Your commerce or OMS layer must define rules based on postcode, weight, deadline and price; DPD simply executes the instruction passed to it.

Address validation and correction are optional

DPD offers address checking via a separate API, but the default integration does not auto-correct or reject invalid addresses. Malformed postcodes and incomplete addresses can slip through to label generation and cause delivery exceptions.

Tracking events are polling or webhook-dependent

DPD does not broadcast tracking events in real time; you must either poll their API at intervals or configure webhooks. Gaps in polling frequency can leave customers without up-to-date tracking information during peak periods.

Returns workflow is manual by default

DPD supports RMA label generation, but the integration does not automatically detect returned parcels, validate restock eligibility or update inventory. Returns matching between DPD and your commerce system must be handled by OMS logic or manual intervention.

Label format and printer integration require configuration

DPD returns label PDFs, but integrating with your warehouse thermal printers, label queues and print-on-demand logic is a separate build. Different warehouse sites may need different label formats and printer destinations.

04 · The real work

Fulfilment teams do not know if a despatch failure was caused by address validation, label print queue backlog, DPD API timeout or missing carrier rules until the order is already late.

05 · Where it sits

Where this integration sits in your estate.

DPD holds the commercial record. The iWeb integration layer manages the rules, mappings, monitoring and exceptions. The commerce platform presents the customer-facing experience. The estate map helps agree ownership before anything is built.

Commerce platform agnostic. Connect DPD across your entire technology stack.

System of record
Source / owner
DPD
Parcel carrier and despatch service
  • Tracking number and barcode generation
  • Label PDF and printer output
  • Transit and delivery event tracking
  • Reverse logistics and return label API
  • Carrier pickup confirmation
iWeb integration layer
Customer-facing commerce
Commerce platform
Adobe CommerceMagento Open SourceShopify PlusBigCommerceOther storefronts
  • Despatch instruction assembly (order lines, address, weight, special instructions)
  • Carrier service selection rules (Next Day, Express, etc.)
  • Order status mapping and customer tracking display
  • RMA initiation and return label requests
  • Exception handling and manual intervention workflows
Connected neighbours
Integration layer
ERP
Receives despatch confirmation for invoice and delivery note generation; stock availability is decremented at despatch.
Integration layer
OMS or Order Management
Holds carrier rules, service selection logic, and special instructions; sends despatch instructions to DPD and receives tracking events back.
Integration layer
WMS or Warehouse Fulfillment
Manages pick-pack flow; receives label PDFs from DPD and routes them to thermal printers; handles label reprinting and print-on-demand logic.
Integration layer
Inventory Management
Stock is decremented when DPD confirms pickup; stock is recounted when returned parcels are received back at the warehouse via DPD reverse logistics.
Integration layer
Customer Account and Notifications
Displays tracking information and delivery status from DPD tracking events; sends proactive notifications (dispatch, in-transit, out-for-delivery, delivered).
Integration layer
Returns and RMA System
Initiates reverse label requests to DPD; matches returned parcels to the original order; coordinates stock recount and credit note generation.
Two-way sync where relevant
06 · Surrounding systems

Systems this integration usually sits next to.

Examples, not a closed list. iWeb is platform-agnostic on both sides: we wire this integration into whatever ecommerce platform and surrounding systems your estate already runs.

Ecommerce platforms (examples)
  • Adobe Commerce
  • Magento Open Source
  • Shopify Plus
  • BigCommerce
  • Other storefronts
Surrounding systems (examples)
  • ERP (inventory and invoice timing)
  • OMS or order management layer (carrier rules and service selection)
  • WMS or warehouse fulfilment system (pick-pack and label printing)
  • Commerce order management (despatch instruction and tracking display)
  • Inventory and stock management (decrement and recount on despatch and returns)
  • Returns and RMA system (reverse label generation and parcel matching)
  • Notification and customer account layer (tracking events and delivery status)
Not sure?

Not sure if this works with your stack?

Tell us what you’re using and what needs to connect. We’ll give you a straight view on what’s possible, what might be awkward, and the safest way to approach it.

07 · Data flows

The data flows we wire.

Each flow has a direction and an owner. We agree both before a line of code is written.

→Into ERP
←From COMMERCE & DPD
↔BOTH WAYS
Despatch instruction export: Order lines, delivery address, weight, service level and special instructions flow from your commerce platform or OMS to DPD via API or file feed
The integration assigns a unique reference per shipment and forwards the instruction to DPD's label generation system.
Tracking and label events: DPD returns tracking numbers, barcode / label PDF, estimated delivery window and handoff confirmation back to commerce and ERP
Tracking events are written to order records so shoppers can follow parcels in real time.
Despatch confirmation and status updates: Once DPD picks up a shipment, confirmation events flow back to commerce; order status shifts from 'packed' to 'despatched'
Subsequent transit and delivery events can be polled or pushed depending on integration design.
Stock movement and despatch reconciliation: Despatched shipment records feed into ERP to trigger invoice and delivery note generation
Stock availability is decremented at despatch, not at order entry, depending on your fulfillment model.
Returns and RMA instructions: Return authorisations with customer location and original tracking reference flow to DPD to request a reverse parcel label
DPD assigns a return barcode and the customer ships the item back through DPD's reverse logistics network.
08 · How we build it

How iWeb configures the integration around your business.

Same method on every integration. The decisions come before the code.

  1. 01
    Shipment instruction mapping and service selection

    We design the flow from commerce order entry through carrier service rules to DPD shipment creation. Weight, postcode and lead time are used to select the right DPD service; special instructions (fragile, signature, depot delivery) are passed correctly.

  2. 02
    Label generation and printer integration

    We connect DPD label PDFs to your warehouse print queues, thermal printers and pick-pack software. We handle label reprinting, print failure recovery and multiple label formats per site or service type.

  3. 03
    Tracking event ingestion and order status synchronisation

    We ingest DPD tracking events via webhook or polling and map them to commerce order status, customer notifications and ERP delivery record triggers. We handle event idempotency and out-of-sequence arrivals.

  4. 04
    Exception queue and remediation workflow

    We surface address validation failures, API timeouts, oversells across multiple carriers, and unacknowledged despatch records in a named queue. Fulfilment teams and integration owners know what broke and how to recover.

  5. 05
    Reverse logistics and RMA label generation

    We integrate DPD's return label API so that RMA initiation automatically triggers a reverse label. We match returned parcels to the original order and coordinate stock recount and financial adjustment with ERP.

  6. 06
    Monitoring, alerting and integration health

    We build dashboards for despatch volume, tracking lag, exception queue depth and DPD API availability. We alert on delivery promise misses, label print failures and unshipped orders held beyond SLA.

09 · Ownership

Who owns what.

The single most important table in any integration. One system owns each field; everything else reads it.

Data
Source / owner
Maintained by
Notes
DataDespatch instructions (order lines, address, weight, service level, special instructions)
Source / ownerCommerce order and OMS
Maintained byOrder entry and fulfilment team
NotesCarrier service rules and special instruction logic are owned by the OMS; DPD executes instructions passed to it.
DataTracking numbers and shipment barcodes
Source / ownerDPD
Maintained byDPD at label generation
NotesReturned to commerce and stored in order record; used as the primary reference for delivery status and customer tracking.
DataTracking events (in-transit, out-for-delivery, delivered, exception)
Source / ownerDPD
Maintained byDPD carrier network
NotesIngested into commerce and ERP via webhook or polling; mapped to order status, delivery notes and customer notifications.
DataDespatch confirmation and invoice trigger timing
Source / ownerERP (for invoice and delivery note generation)
Maintained byIntegration logic based on DPD pickup confirmation
NotesDPD pickup event triggers invoice generation in ERP; finance and fulfilment teams rely on this timing for reconciliation and stock decrement.
DataReturns authorisations (RMA number, reason, original tracking reference)
Source / ownerCommerce OMS
Maintained byCustomer service and returns team
NotesPassed to DPD to initiate reverse label; return parcel tracking is matched back to the original order for stock and financial adjustment.
DataLabel format, printer destination and warehouse print rules
Source / ownerCommerce or WMS configuration
Maintained byFulfilment and IT operations
NotesDifferent sites may require different label formats, printer queues and print-on-demand logic; not owned by DPD.
DataException queue (address failures, API timeouts, delivery promise misses)
Source / ownerIntegration
Maintained byIntegration owner and fulfilment operations
NotesExceptions are surfaced to a named queue; resolution is manual or scripted by operations team, not automatic.
10 · Experienced integrator

Built this before

iWeb has integrated DPD into commerce and ERP estates across retail, foodservice and logistics operators. We understand how despatch instructions, label generation and tracking events flow between your order, warehouse and carrier systems.

We design service selection rules so that carrier choice is governed in your OMS, not hardcoded in the integration, allowing rule changes without deployment.
We handle address validation, label reprinting and printer integration so that warehouse throughput is not blocked by API or print failures.
We implement exception queues for address failures, API timeouts and orphaned shipments so that fulfilment teams know what broke and how to recover.
We ingest DPD tracking events via webhook or polling and map them to order status, delivery notes and customer notifications with idempotency and recovery logic.
We coordinate despatch confirmation with ERP invoice timing and inventory decrement so that stock and financial records stay aligned with physical despatch.
11 · Before launch

What we test before launch.

Every one of these is rehearsed before a customer ever sees the integration.

Verify label generation and barcode assignment for orders with valid UK postcodes, and confirm invalid postcodes are either rejected or flagged in an exception queue.
Test despatch confirmation timing: confirm that stock decrement and ERP invoice generation are triggered when DPD confirms pickup, not when the order is packed.
Confirm that tracking events from DPD (in-transit, out-for-delivery, delivered) are ingested and mapped to order status within your polling or webhook SLA.
Test label reprint and carrier API outage fallback: confirm that warehouse staff can trigger reprints and that a DPD API outage does not halt all despatch.
Verify RMA label generation and reverse parcel reconciliation: test that returned parcels are matched to the original order and that stock recount is triggered when the parcel is received.
Confirm monitoring and alerting: validate that despatch delays, label print failures, unshipped orders and DPD API outages surface in an exception queue with named owners.
Test multi-site and multi-carrier behaviour: confirm that orders are routed to the correct site and that DPD integrates cleanly alongside other carriers.
12 · Failure points

Common risks and where they bite.

We name these on day one. A risk written down is a risk you can plan around.

Address validation gaps causing delivery failures

If the integration does not enforce postcode format or validate addresses against DPD's database before label creation, invalid or incomplete addresses slip through. The parcel is returned to your warehouse as undeliverable and the customer complains after the promised delivery date has passed.

Tracking events arrive out of sequence or are missed

If tracking is polled at fixed intervals, events may arrive out of sequence or be lost during peak despatch windows. Customers see stale or wrong status; finance cannot reconcile invoice timing to actual despatch.

Label reprinting is manual or blocks pick-pack flow

If the integration does not handle label failures, reprints or printer outages smoothly, warehouse staff are forced to wait or manually resubmit to DPD. Pick-pack stations back up and despatch SLA slips.

Service selection rules drift or are hardcoded

If carrier rules (Next Day vs Express, signature requirements, depot delivery) are embedded in the integration code, changing them requires a deployment and testing. Peak season rule changes slip or are missed.

Returns parcels are not reconciled to original orders

If returned parcels from DPD are not matched back to the original order and RMA, stock recount and financial adjustment are delayed or misaligned. Inventory records diverge from physical stock and credit notes are issued late.

DPD API outage breaks despatch without fallback

If the integration does not implement timeout handling, circuit breakers or fallback label generation (e.g., generic print-at-ship labels), a DPD API outage stops all despatch. Orders pile up and delivery promises are missed.

13 · Where it applies

Relevant services and sectors.

14 · Questions

Common questions about DPD integrations.

How does carrier service selection work? Can we use DPD Next Day for some orders and Express for others?

Service selection rules live in your commerce order or OMS layer, not in DPD. You define rules based on postcode area, parcel weight, order total and delivery deadline; the integration passes the selected service to DPD at despatch. Changing service rules does not require integration changes, only OMS configuration updates.

What happens if DPD's API is down? Can we still despatch orders?

If DPD is unreachable, the integration should pause despatch and surface the error in an exception queue. You can configure a fallback such as generic label printing at the warehouse, but this requires explicit design. Without a fallback, despatch stops until DPD service is restored.

How quickly do tracking events appear in customer accounts after despatch?

Tracking freshness depends on the ingestion method. Webhook integration updates tracking within seconds of DPD events; polling-based integration may lag by 15-60 minutes depending on poll frequency. Peak despatch periods may cause polling delays if the integration is not tuned for throughput.

Can we use multiple carriers (DPD, Royal Mail, UPS, etc.) from one integration?

Yes. The integration routes shipments to DPD based on carrier selection rules; other carriers are handled via separate integrations. Your OMS or commerce layer orchestrates which carrier receives each shipment based on service, cost and destination.

How are returned parcels matched back to the original order for stock recount?

Returned parcel tracking numbers must be linked to the original order reference in your system. This typically happens when the customer initiates the RMA and provides the original order number. The integration tracks the return parcel through DPD and triggers stock recount and credit note generation when the parcel is received back at your warehouse.

What address validation does DPD provide? Can we prevent invalid postcodes from creating labels?

DPD offers postcode validation via a separate API call. The integration can be configured to validate addresses before label creation, but this is not automatic. If address validation is not enforced, invalid or incomplete addresses can slip through and cause delivery failures.

How do we handle special instructions like 'signature required' or 'leave in safe place'?

Special instructions are defined in your commerce or OMS order record and passed to DPD in the despatch instruction. DPD respects these instructions during delivery. If instructions are not propagated correctly, DPD delivers using default behaviour (e.g., signature not required, no safe place delivery).

Can we reprint a label if the first one is damaged or lost?

Yes. The integration can resubmit the shipment to DPD with the same order reference, and DPD will regenerate the label with the same tracking number. You should test this path before peak season so warehouse staff know how to trigger reprints without causing duplicate shipments.

How does the integration handle delivery promise misses (e.g., Next Day delivery that arrives late)?

DPD provides tracking status, but the integration does not automatically detect or escalate delivery promise failures. You must define SLA rules in your monitoring layer (e.g., flag if tracking shows 'not delivered' after the promised date). Late deliveries are then surfaced for customer service follow-up.

What happens to despatch records if the connection between commerce and DPD is interrupted mid-shipment?

If the connection breaks after DPD assigns a tracking number but before confirmation reaches commerce, the order can become orphaned. The integration should implement idempotency keys and reconciliation queries to detect and recover orphaned shipments before they cause invoice or stock reconciliation errors.

How do we split inventory across multiple fulfilment sites or 3PLs if only some use DPD?

Your OMS or inventory layer determines which site ships each order, and the integration sends the appropriate instruction to DPD (for DPD-enabled sites) or another carrier (for other sites). Stock is decremented and despatch instructions are routed based on this site selection logic.

Can DPD labels be printed at multiple warehouse locations with different thermal printer settings?

Yes. The integration can be configured to route labels to different print queues or printer destinations based on warehouse location or service type. However, this requires explicit print-routing logic in the integration or WMS, not built into DPD.

How is the timing of invoice generation handled in ERP? Is it triggered when we despatch or when DPD picks up?

This depends on your business model. The integration should trigger invoice generation when DPD confirms pickup (despatch confirmation), not when the order is packed. This aligns ERP invoice timing with actual despatch and reduces reconciliation friction. Your ERP and fulfilment process should be configured to match this timing.

What monitoring and alerting should we set up to ensure the integration stays healthy?

Monitor despatch volume (orders sent to DPD per hour), label generation success rate, tracking event ingestion lag, exception queue depth, and DPD API availability. Alert on delivery promise misses, label print failures, unshipped orders older than SLA, and repeated API timeouts. Tracking lag beyond your polling interval is also a sign of capacity issues.

Next step

Have a DPD integration brief?

Send the brief, or tell us what is breaking. You will get a written response from a senior expert: the integration boundary, the realistic shape, the risks worth naming, and what it takes to support after launch.
Talk to an expertOr browse all integrations →