Integration and Interfaces

Technical integration is the backbone of every Fulfillment by DHL partnership. Without functioning interfaces between shop, order management system (OMS), warehouse management and the DHL fulfillment center, orders stall, inventory diverges and customers receive no tracking information. Those who plan integration cleanly from the start save weeks of troubleshooting after go-live and scale smoothly beyond Black Friday, marketplace peaks and international expansion.

This guide explains which interfaces DHL Fulfillment typically offers, how data flows between your systems and the fulfillment center, and which steps merchants should follow for stable integration. It complements DHL Fulfillment scope of services with the IT perspective and links it to general selection criteria for technical integration with 3PL partners.

Why integration is critical

Fulfillment by DHL is not an isolated shipping service but a fully integrated 3PL process. Your shop generates orders, DHL picks and ships in the warehouse – interfaces are the bridge in between. Errors in this bridge directly affect customer satisfaction, marketplace ratings and operational costs.

Typical consequences of poor integration:

  • Double shipment or no shipment – Orders are not transmitted or triggered twice
  • Inventory discrepancies – Shop shows availability, warehouse reports stockout
  • Missing tracking – Customers receive no tracking number, support workload increases
  • Delayed returns – Returns are not booked in the WMS, B-stock remains invisible
  • SLA violations – Cut-off times are missed because orders arrive too late
Important: Integration is not a one-time IT project but an ongoing process. Shop updates, new marketplaces, SKU expansions and DHL rate changes require regular coordination between merchant IT, middleware provider and DHL Fulfillment.

System landscape at a glance

With DHL Fulfillment, at least three systems work together: your sales system (shop, marketplace, ERP), optionally middleware or an OMS, and the warehouse management system (WMS) at the DHL fulfillment center. DHL provides the data bridge between these worlds via standardized or customized interfaces.

DHL Fulfillment IT integration

1
Shop/Marketplace
2
OMS/Middleware
3
DHL Fulfillment API
4
WMS DHL Center
5
DHL Shipping/Tracking
6
Feedback to shop

Bidirectional data flows between OMS/middleware and DHL Fulfillment API (orders in, status out) and from DHL shipping/tracking back to the shop. Real-time calls are automated; batch imports (ASN, inventory) run at defined intervals.

Core systems and their roles

  1. Shop system – Receives orders, displays inventory, triggers shipping
  2. OMS / ERP – Consolidates multi-channel orders, validates addresses, controls priorities
  3. Middleware – Translates formats between shop and DHL (REST, EDI, CSV)
  4. DHL Fulfillment interface – Receives orders, reports inventory and shipping status
  5. WMS at fulfillment center – Controls pick-pack-ship, inventory, returns
  6. DHL shipping API – Generates labels, tracking events, proof of delivery

More on the terms in the glossary for OMS and WMS.

Interface types compared

DHL Fulfillment supports different integration paths depending on contract scope and volume. The choice depends on your IT resources, shop system and desired level of automation.

Interface type
Typical use
Advantages
Disadvantages
Automation
REST API
Real-time order export, status feedback
Fast, bidirectional, scalable
Development effort, watch API versioning
Very high
EDI (EDIFACT/XML)
High volume, enterprise ERP, B2B
Standardized, auditable, mass-capable
Setup costs, longer rollout
High
Native shop connector
Shopify, Shopware, WooCommerce
Fast go-live, little custom development
Dependency on connector provider
Medium to high
CSV/SFTP batch
Start phase, niche shops, pilot projects
Simple, low entry barrier
Delay, manual errors, no real-time inventory
Low
Middleware (e.g. Billbee, JTL)
Multi-channel, multiple 3PLs simultaneously
Central control, format translation
Additional costs, another error source
High
Tip: Start with the integration path DHL has already certified for your shop system. Custom development only pays off at higher order volume or with very specific process requirements.

Data flows: What is transmitted when?

Stable fulfillment integration depends on clearly defined data flows in both directions. The following overview shows the most important message types and their typical frequency.

Data type
Direction
Content
Typical frequency
Order
Merchant → DHL
SKU, quantity, delivery address, shipping service, reference
Real-time after payment received
Inventory reconciliation
DHL → Merchant
Available quantity per SKU, blocked stock, quarantine
Hourly to daily
ASN (Advance Shipping Notice)
Merchant → DHL
Goods receipt: SKU, quantity, batch, ETA
Before each supplier delivery
Ship confirmation
DHL → Merchant
Tracking number, carrier, ship date, weighted line items
After label print at center
Tracking events
DHL → Merchant/Shop
Status codes, delivery attempts, POD
At each scan in DHL network
Return notification
DHL → Merchant
Return reason, condition, restocking
After goods receipt of return

Details on the Advance Shipping Notice can be found under ASN and Advance Shipping Notice. For shipping labels and carrier APIs in general: Shipping labels and carrier API.

Shop integration and multi-channel

Most merchants do not run only their own shop but also sell via Amazon, eBay, Otto or other marketplaces in parallel. DHL Fulfillment must therefore be able to process orders from all channels – ideally centrally via an OMS or middleware, not separately per channel.

Recommended architecture for multi-channel

  1. Central order hub – All marketplace and shop orders flow into one OMS or middleware
  2. Unified SKU logic – Same item number across all channels, no duplicates in the WMS
  3. Prioritization rules – Express orders and premium marketplaces before standard orders
  4. Inventory distribution – One inventory pool at the DHL center, no double bookings between channels
  5. Tracking feedback – Tracking number automatically returned to each sales channel

Detailed guidance on shop integration in multi-channel fulfillment and onboarding with the fulfillment partner helps with planning.

Warning: Marketplaces such as Amazon or eBay have their own SLAs for shipping confirmation and tracking. If feedback from the DHL center is delayed, account penalties may follow – regardless of whether the goods are already physically in transit.

Implementation: Step by step

Introducing DHL Fulfillment integration follows a fixed pattern in practice. Plan typically four to eight weeks for full integration – depending on shop system, middleware and test scope.

Phase 1: Requirements analysis

  1. As-is assessment – Which systems are in use (shop, ERP, PIM, middleware)?
  2. Data model – SKU structure, variants, bundles, batches, best-before dates
  3. Process definition – Cut-off times, express priority, returns workflow
  4. Interface selection – API vs. EDI vs. connector; coordination with DHL integration team
  5. SLA definition – Maximum transmission time order → WMS, inventory update frequency

Phase 2: Master data and mapping

  1. SKU alignment – Merchant SKU = WMS SKU, unique barcodes/EANs
  2. Address validation – Routing codes, parcel locker fields, international formats
  3. Map shipping products – DHL Parcel, small parcel, express per order type
  4. Return address – Set fixed return address of fulfillment center
  5. Test data set – At least 20 representative SKUs including edge cases

Phase 3: Development and configuration

  1. Sandbox access – Request test API or EDI test environment from DHL
  2. Build order export – Trigger after payment received or manual release
  3. Inventory sync – Pull or push; define conflict rules for discrepancies
  4. Process ship confirmation – Tracking to shop and customer communication
  5. Error handling – Retry logic, dead-letter queue, alerting on outage

Phase 4: Testing and go-live

  1. Unit tests – Individual API calls with mock data
  2. End-to-end tests – Real test order from shop to delivery
  3. Load test – Simulated peak order volume (e.g. 3× daily average)
  4. Parallel operation – Short phase with manual reconciliation before full switchover
  5. Go-live window – Do not start before holidays or peak seasons

Integration go-live

1
Requirements
2
Master data
3
Development
4
E2E test
5
Production operation

Each phase ends with a check gate before the next begins. Production operation starts only when all end-to-end tests have been completed successfully.

Mandatory fields and data quality

Poor master data is the most common cause of integration problems. DHL Fulfillment rejects or delays orders when mandatory fields are missing or addresses cannot be validated.

Minimum requirements per outbound order:

  • Unique order reference (shop order number)
  • Complete delivery address including country and postal code
  • SKU with valid item number and ordered quantity
  • Shipping service (standard, express, parcel locker if desired)
  • Sender/return identifier per contract

Common data errors:

  • Special characters in SKU names (slashes, spaces)
  • Parcel locker without post number or incorrect branch number
  • Bundle items as single SKU instead of bill of materials
  • Duplicate order reference on retry without idempotency key
  • Incorrect weight for shipping-cost-relevant products

Data quality before go-live

  • SKU mapping 100% covered
  • EAN/barcode checked per item
  • Address validation active
  • Parcel locker logic tested
  • ASN submitted for initial goods receipt
  • Return address configured
  • Idempotency on order export
  • Monitoring alerts set up

Monitoring, KPIs and troubleshooting

After go-live, integration work does not end. Continuous monitoring secures SLAs and detects deviations before customers notice.

Important integration KPIs

KPI
Target value (guideline)
Measurement point
Order transmission rate
> 99.5% without manual intervention
Shop → DHL API
Transmission latency
< 5 minutes after order release
Timestamp order vs. WMS receipt
Inventory discrepancy
< 1% of SKUs per reconciliation
Shop inventory vs. WMS report
Tracking feedback
> 99% within 2 hours after shipping
Ship confirmation → Shop
API error rate
< 0.5% of all requests
HTTP 4xx/5xx, timeout

Integration stability after go-live

Month 1

Order transmission rate typically around 95% – troubleshooting and master data cleanup ongoing

Month 3

Stabilization to around 98–99% through optimized retry logic and mapping corrections

Month 6

Target reached: around 99.8% without manual intervention in regular operation

Typical errors and solutions

  1. Order stuck in queue – Check middleware log, API credentials and rate limits
  2. Inventory too high in shop – Increase sync frequency, check blocked stock in WMS
  3. No tracking for customer – Activate ship confirmation webhook/polling
  4. ASN rejected – SKU does not exist in WMS; create master data before delivery
  5. Double shipment – Set idempotency key on order reference, limit retry logic

Security, data protection and compliance

Fulfillment interfaces transmit personal customer addresses and order data. This requires technical and contractual safeguards.

Technical minimum standards:

  • Encrypted transmission (TLS 1.2 or higher)
  • API authentication via OAuth, API key or certificate – no plaintext credentials
  • IP whitelisting where provided for in the contract
  • Logging without storing unnecessary personal data
  • Regular credential rotation

Contractual:

  • Data processing agreement (DPA) with DHL as processor
  • Clear deletion periods for customer data in logs and test systems
  • Documented escalation paths for data incidents

Integration vs. pure DHL shipping

Fulfillment by DHL differs technically from classic DHL business customer shipping. Those who only print labels via the business customer portal do not need WMS integration – those who outsource warehouse and shipping need the full fulfillment interface.

Aspect
DHL Fulfillment integration
Shipping API only
Scope
Warehouse + shipping + returns
Label and tracking only
Inventory sync
Yes, bidirectional
No
ASN/goods receipt
Yes
No
Typical user
3PL customer with outsourcing
In-house warehouse with DHL shipping

More context on the overall offering: DHL Fulfillment by DHL.

Practical checklist: Successfully completing integration

Before production start, all items on this checklist should be fulfilled:

  • Interface type agreed and documented with DHL
  • Sandbox tests for order, inventory and ship confirmation passed
  • At least one end-to-end test order physically delivered
  • SKU master data 100% created in WMS
  • ASN for initial goods receipt successfully submitted
  • Cut-off times considered in shop workflow
  • Tracking feedback active for all sales channels
  • Monitoring and alerting configured for API outage
  • Escalation contacts at DHL and middleware on file
  • Rollback plan defined for go-live day

Typical integration timeline

W1–2
Requirements and mapping
W3–4
Sandbox development
W5–6
End-to-end tests
W7
Parallel operation
W8
Go-live (avoid peak seasons)

Conclusion

Integration with DHL Fulfillment is the key to realizing the promised scaling and efficiency gains from the outsourcing model. REST APIs, EDI, native connectors or middleware – the right choice depends on volume, IT capacity and multi-channel complexity. What matters is not only technical implementation but data quality, end-to-end monitoring and structured onboarding.

Those who treat interfaces as a strategic project from the start avoid costly rework, meet marketplace SLAs and reliably deliver tracking and short delivery times to customers – whether ten or ten thousand orders per day.

Related topics