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
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
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
- Shop system – Receives orders, displays inventory, triggers shipping
- OMS / ERP – Consolidates multi-channel orders, validates addresses, controls priorities
- Middleware – Translates formats between shop and DHL (REST, EDI, CSV)
- DHL Fulfillment interface – Receives orders, reports inventory and shipping status
- WMS at fulfillment center – Controls pick-pack-ship, inventory, returns
- DHL shipping API – Generates labels, tracking events, proof of delivery
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.
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.
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
- Central order hub – All marketplace and shop orders flow into one OMS or middleware
- Unified SKU logic – Same item number across all channels, no duplicates in the WMS
- Prioritization rules – Express orders and premium marketplaces before standard orders
- Inventory distribution – One inventory pool at the DHL center, no double bookings between channels
- 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.
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
- As-is assessment – Which systems are in use (shop, ERP, PIM, middleware)?
- Data model – SKU structure, variants, bundles, batches, best-before dates
- Process definition – Cut-off times, express priority, returns workflow
- Interface selection – API vs. EDI vs. connector; coordination with DHL integration team
- SLA definition – Maximum transmission time order → WMS, inventory update frequency
Phase 2: Master data and mapping
- SKU alignment – Merchant SKU = WMS SKU, unique barcodes/EANs
- Address validation – Routing codes, parcel locker fields, international formats
- Map shipping products – DHL Parcel, small parcel, express per order type
- Return address – Set fixed return address of fulfillment center
- Test data set – At least 20 representative SKUs including edge cases
Phase 3: Development and configuration
- Sandbox access – Request test API or EDI test environment from DHL
- Build order export – Trigger after payment received or manual release
- Inventory sync – Pull or push; define conflict rules for discrepancies
- Process ship confirmation – Tracking to shop and customer communication
- Error handling – Retry logic, dead-letter queue, alerting on outage
Phase 4: Testing and go-live
- Unit tests – Individual API calls with mock data
- End-to-end tests – Real test order from shop to delivery
- Load test – Simulated peak order volume (e.g. 3× daily average)
- Parallel operation – Short phase with manual reconciliation before full switchover
- Go-live window – Do not start before holidays or peak seasons
Integration go-live
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
Integration stability after go-live
Order transmission rate typically around 95% – troubleshooting and master data cleanup ongoing
Stabilization to around 98–99% through optimized retry logic and mapping corrections
Target reached: around 99.8% without manual intervention in regular operation
Typical errors and solutions
- Order stuck in queue – Check middleware log, API credentials and rate limits
- Inventory too high in shop – Increase sync frequency, check blocked stock in WMS
- No tracking for customer – Activate ship confirmation webhook/polling
- ASN rejected – SKU does not exist in WMS; create master data before delivery
- 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.
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
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.