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

Frequently Asked Questions about DHL Fulfillment Integration and Interfaces

Question
Answer
Which interface types does DHL Fulfillment support and how do I choose the right one?
DHL Fulfillment supports several paths depending on contract scope and volume: REST API for real-time order export and status feedback, EDI (EDIFACT/XML) for high-volume enterprise ERP and B2B, native shop connectors for Shopify, Shopware or WooCommerce, CSV/SFTP batch for pilots and niche shops, and middleware such as Billbee or JTL for multi-channel setups. The choice depends on your IT resources, shop system and desired automation level. The page recommends starting with a path DHL has already certified for your shop system; custom development typically pays off only at higher order volumes or with very specific process requirements.
Which systems are involved in DHL Fulfillment IT integration and how do data flows run?
At least three systems work together: your sales system (shop, marketplace or ERP), optionally middleware or an OMS, and the WMS at the DHL fulfillment center. The typical chain runs from shop/marketplace through OMS/middleware to the DHL Fulfillment API, then into the WMS, on to DHL shipping and tracking, and finally feedback back to the shop. Orders flow merchant to DHL in real time after payment; inventory reconciliation returns available, blocked and quarantine stock hourly to daily; ASN messages announce goods receipt before supplier deliveries; ship confirmations and tracking events return tracking numbers and status codes after label print and each network scan; return notifications report reason, condition and restocking after return goods receipt.
How should multi-channel shops connect Amazon, eBay or Otto to DHL Fulfillment?
Orders from all channels should flow into one central OMS or middleware rather than separate per-channel integrations. Use the same SKU across channels so the WMS has no duplicates, apply prioritization rules for express and premium marketplace orders, keep one shared inventory pool at the DHL center to avoid double bookings, and return tracking numbers automatically to each sales channel. Marketplace SLAs for shipping confirmation and tracking are strict: delayed feedback from the DHL center can trigger account penalties even when goods are already physically in transit.
How long does a typical DHL Fulfillment integration take and what are the main phases?
Full integration typically takes four to eight weeks depending on shop system, middleware and test scope. Phase 1 covers requirements analysis (systems inventory, data model, cut-offs, interface choice, SLAs). Phase 2 aligns master data and mapping (SKU equals WMS SKU, address validation, shipping products, return address, at least 20 test SKUs). Phase 3 builds sandbox access, order export, inventory sync, ship confirmation handling and error handling with retries and alerting. Phase 4 runs unit, end-to-end and load tests, a short parallel-operation window and go-live outside holidays or peak seasons. Each phase ends with a check gate; production starts only after successful end-to-end tests.
Which mandatory fields and data-quality checks prevent order rejection at go-live?
Poor master data is the most common integration failure. Each outbound order needs a unique order reference, a complete delivery address with country and postal code, a valid SKU with quantity, a shipping service (standard, express or parcel locker) and the contractual sender/return identifier. Frequent errors include special characters in SKU names, parcel lockers without post number or wrong branch number, bundles sent as a single SKU instead of a bill of materials, duplicate order references on retry without an idempotency key, and incorrect weights. Before go-live, cover SKU mapping fully, verify EANs/barcodes, activate address validation, test parcel locker logic, submit ASN for initial goods receipt, configure the return address, enforce idempotency on order export and set monitoring alerts.
Which integration KPIs should be monitored after go-live and how do common errors get fixed?
Guideline targets include an order transmission rate above 99.5 percent without manual intervention, transmission latency under five minutes after order release, inventory discrepancy under one percent of SKUs per reconciliation, tracking feedback above 99 percent within two hours after shipping, and an API error rate under 0.5 percent. Stability often rises from around 95 percent transmission in month one to about 98–99 percent by month three and around 99.8 percent by month six. Typical fixes: check middleware logs, credentials and rate limits for stuck orders; raise sync frequency and check blocked WMS stock if shop inventory is too high; activate ship-confirmation webhook or polling when tracking is missing; create missing WMS master data before ASN deliveries; and use an idempotency key on the order reference to prevent double shipment.
How does DHL Fulfillment integration differ from using only the DHL shipping API?
Fulfillment by DHL covers warehouse, shipping and returns with bidirectional inventory sync and ASN/goods-receipt messaging for 3PL customers who outsource fulfillment. A shipping-API-only setup only creates labels and tracking for merchants who keep an in-house warehouse. Anyone who only prints labels via the business customer portal does not need WMS integration; anyone who outsources warehouse and shipping needs the full fulfillment interface including inventory, ASN, ship confirmation and return notification flows.