DHL Supply Chain is the contract logistics division of DHL Group, and it is a different kind of connector from every parcel carrier in this catalogue. It does not sell a shipping product off a rate card. It runs warehouses, transport and fulfilment operations for a client under a multi-year contract, on a warehouse management system and an interface specification agreed for that client. As a result there is no DHL Supply Chain API, no developer portal and no sign-up. This page says exactly that, documents the two surfaces that do exist, and sets out what to ask for when the contract is negotiated, because that conversation is where the integration is actually defined.
At a glance
For the DHL APIs that are public, MyDHL Express, DHL eCommerce Solutions and the unified Shipment Tracking API, see /connectors/dhl. That page covers authentication, endpoints, sample responses and rate limits in full. This page is only about the Supply Chain division, which has none of those.
What it is
The contract logistics arm of DHL Group, headquartered in Bonn, and the global market leader in that sector. Its modern shape comes from DHL's 2005 acquisition of the British logistics group Exel. It operates across North America, South America, Asia Pacific, EMEA and the UK and Ireland.
What it sells:
- warehousing and distribution, in DHL operated or client operated sites
- managed transport, including lead logistics provider arrangements where DHL manages other carriers on the client's behalf
- e-fulfilment and returns management
- packaging and technical services
- business process outsourcing and supply chain consulting
Named sector specialisms are automotive, engineering and manufacturing, chemicals and energy, consumer and retail, technology, and life sciences and healthcare. The last of those has been reinforced by acquisitions, Eurodifarm in 2011 and the healthcare logistics provider SDS Rx announced in 2025.
Divisional revenue is commonly quoted at around 14 billion euros, but the figures readily available are several years old and the employee counts circulating publicly conflate the division with DHL Group as a whole. dhl.com and group.dhl.com both refused to serve the pages with the current numbers to the fetcher used for this research, so no scale figure here is first-party and none should be quoted in a document that matters. Take current figures from DHL Group's annual report.
For a commerce database DHL Supply Chain is a fulfilment provider and a carrier, never a sales channel. Where it runs a client's e-fulfilment, it is the source of inventory, locations, shipments and returns.
API access
There is none, and this was checked rather than assumed.
The DHL developer catalogue at developer.dhl.com/api-catalog publishes APIs grouped by division: DHL Express, DHL eCommerce, DHL Freight, Post and Parcel Germany, DHL Global Forwarding and DHL Supply Chain. Searching it for supply chain returns exactly one result, and it is not a Supply Chain API:
Every other catalogue entry belongs to Express, eCommerce, Freight or Post and Parcel Germany. There is no shipment creation API, no inventory API, no order API and no warehouse API for Supply Chain.
The tracking API's own documentation lists DHL Supply Chain in its scope, but its service parameter enumeration contains no supply chain value: the documented values are express, express-acs, ecommerce, ecommerce-europe, ecommerce-iberia, ecommerce-tr, freight, parcel-de, parcel-nl, parcel-uk, parcel-pl, sameday and svb. So a Supply Chain consignment is either tracked under whichever DHL carrier actually moved it, or is not reachable through that API at all. Do not assume a Supply Chain waybill will resolve there. Test with a real number before designing around it.
The two surfaces that do exist
MySupplyChain, branded MySC. A customer portal at https://mysupplychain.dhl.com, a React single page application, entirely login-gated. Its own page description reads: "DHL MySC. Your one-stop-shop for supply chain data, insights and tools." It is served from mysupplychain.gocec.dhl.com. Nothing about its contents, its reports or any export or interface is public. For a client with a contract, this is where the operational data lives and the first place to ask whether a scheduled export or an interface exists.
The shared tracking API. Documented at developer.dhl.com/api-reference/shipment-tracking, with self-serve key registration, a DHL-API-Key header, a sandbox at https://api-test.dhl.com/track and a push variant. Covered in full at /connectors/dhl, with the caveat in the warning above.
How integration actually happens
In contract logistics the interface is part of the contract, not a product. What that means in practice:
- The commercial engagement defines the scope: which sites, which flows, which systems of record.
- DHL and the client agree an interface specification document covering message types, formats, transport, cut-off times, acknowledgements, error handling and volumes.
- Messages are typically EDI, ANSI X12 in North America or UN/EDIFACT in Europe, or delimited or fixed-width flat files, or increasingly a client-specific web service. The transport is typically AS2, SFTP or a value-added network.
- The warehouse management system at the site determines which message types are natively supported and how much configuration is needed. DHL runs several, and the answer differs by site.
- Testing happens in a named integration environment agreed for the project, not a public sandbox.
None of that is published by DHL, so nothing more specific can be written here without inventing it. What can be said is what to ask for, and that is set out under each object below.
Authentication
Not published for this division. For the shared tracking API it is a static DHL-API-Key header obtained by registering an application on the developer portal.
For a contract interface, authentication is whatever the transport uses: AS2 certificates, SFTP keys, or mutual TLS and a token on a web service. Settle it in the interface specification, and insist on per-environment credentials and a documented rotation procedure, because contract logistics integrations tend to outlive the people who set them up.
Objects we can read
No schema is published for anything in this division. Each section below states what exists operationally and what to request.
Orders
DHL Supply Chain does not hold a sales order. It receives an outbound order, a despatch instruction, from the client's order management or e-commerce system and fulfils it. The system of record stays with the client. Read orders from the sales channel connector.
Ask for: the outbound order message and its acknowledgement, the order status message and its status vocabulary, and the cut-off times that govern same-day release.
Order items
Carried as lines on the outbound order and on the despatch confirmation, with SKU, quantity ordered, quantity picked and quantity short. Short picks are the field that matters most and the one most often omitted from a first-pass specification. Ask for it explicitly.
Products and listings
Not applicable as listings. DHL holds an item master for the SKUs it stores: code, description, dimensions, weight, handling and storage attributes, batch and serial control flags, and shelf-life rules where relevant. That master is maintained by an item master message from the client.
Ask for: the item master message, who owns each field, and what happens when a dimension changes on a SKU already in stock.
Inventory
The single most valuable object in this connector, and the reason a contract logistics provider belongs in a commerce database at all. DHL holds stock at its sites and reports it.
Ask for: a periodic stock snapshot by SKU by site, ideally including status buckets for available, allocated, quarantined and damaged; a stock movement or adjustment message so discrepancies can be traced rather than just observed; batch, lot and expiry where the sector requires it; and the cycle count and annual stocktake reporting schedule, because reconciliation breaks will always be found there first.
Shipments and tracking
Outbound consignments are handed to a carrier, which may be another DHL division or a third party managed by DHL under a lead logistics provider arrangement. So the tracking identifier usually belongs to the moving carrier, not to DHL Supply Chain.
Ask for: the despatch advice or advanced shipping notice, carrying the carrier name, the tracking number and the package and carton structure. That is the message that lets you join a fulfilment event to a carrier scan, and without it the two halves of the shipment record cannot be connected.
Returns and cancellations
Returns management is a named DHL Supply Chain service, including receipt, inspection, grading and disposition.
Ask for: the returns receipt message with the disposition code, whether the returned unit restocks as sellable, and how the grading vocabulary maps onto your own. Also ask about order cancellation: the window in which a released order can still be pulled before despatch is an operational answer, not a technical one, and it is usually shorter than expected.
Proof of delivery
Where DHL controls the final leg, an electronic proof of delivery exists. Where a third-party carrier does, it belongs to that carrier. Ask which applies per flow, because clients frequently assume the first and get the second.
Payments and settlements
Not applicable. DHL Supply Chain invoices the client for logistics services under the contract. There is no marketplace remittance, no COD float in the usual sense, and no settlement report of the kind other connectors in this catalogue produce. Billing detail arrives as an invoice with supporting activity data, on whatever schedule the contract specifies.
Customers
Consignee name, address and contact details ride on every outbound order and despatch advice. All PII. DHL is a processor acting on the client's instruction; that relationship should already be papered in the contract, and the retention period for consignee data in DHL's systems is worth confirming.
Locations
DHL operated warehouses and distribution centres, plus any client sites DHL manages. The site list for a given contract is contractual, not published.
Ask for: a stable site identifier that appears on every message, and the mapping from it to a physical address. Site codes are the join key for everything else and they are easy to get wrong once a network has more than a handful of sites.
Writing back: listings, price and stock
Not applicable. This is a logistics provider, not a sales channel: there are no listings to publish, no prices to set and no stock levels to write to a marketplace.
The write direction that does exist is instructions into DHL's warehouse:
- the item master, creating and updating SKUs DHL is allowed to receive
- the inbound advice or purchase order, telling the site what to expect, from whom and when
- the outbound order, releasing a despatch
- the order amendment or cancellation, within the agreed cut-off
- returns authorisation, where the client pre-notifies an expected return
Every one of those is defined in the contract's interface specification. No message format, field list or batch limit can be stated here without inventing it, and the honest answer is that they differ by site and by client.
Webhooks and notifications
Not published for this division. In a contract logistics integration the equivalent of a webhook is an outbound message on an agreed schedule or trigger: a despatch confirmation as orders ship, a stock snapshot nightly, a receipt confirmation as inbound is put away.
Ask for: which messages are event-triggered versus batched, the batching windows, whether acknowledgements are functional, an EDI 997 or CONTRL, or semantic, and the retry and escalation behaviour when a message fails. Agree an alerting path for a missed file, because a silent gap in a nightly stock snapshot is the most common and most damaging failure mode in this class of integration.
The shared Shipment Tracking Unified Push API is available across DHL and is described at /connectors/dhl, subject to the service enum caveat above.
Rate limits and pagination
Not published for this division. Contract interfaces are governed by volume commitments and cut-off times rather than by requests per second: expect the specification to state expected daily message volumes and peak windows instead of a rate limit.
For the shared tracking API, DHL's published limits apply and are documented on the developer portal.
Mapping to the unified model
No field names exist in public, so the right column names the message that would carry each concept in a conventional contract logistics interface. Treat it as a checklist for the specification conversation, not as a description of a DHL product.
Gaps and open questions
- No public API, no public interface specification, no public message catalogue. Everything technical about this division is behind a contract, and that is by design rather than an oversight.
- The contradiction in the tracking API is unresolved: DHL Supply Chain is listed in scope but has no
serviceenum value. Whether a Supply Chain consignment resolves there, and under which service, needs a live test with a real number. - MySupplyChain is completely opaque from outside. Whether it offers scheduled exports, a report API or only screens is unknown and is the cheapest thing a contracted client can find out.
- Which warehouse management systems DHL runs at which sites is not public, and it determines what the interface can support.
- No scale figure on this page is first-party.
dhl.comandgroup.dhl.comwould not serve to the fetcher used here, and the figures circulating elsewhere are several years old and conflate the division with the group. Take current numbers from the DHL Group annual report. - The EDI and flat file integration model described above is the standard pattern for contract logistics and is consistent with everything observable, but no DHL document confirming it for this division was found in public. It is presented as the shape to expect and the checklist to bring, not as a DHL specification.
Sources
- DHL developer API catalogue, read 2026-09-22, and searched for supply chain, establishing that no DHL Supply Chain specific API exists and that the division appears only as a tag on the shared tracking API
- DHL Shipment Tracking Unified API reference, for the division scope list and the
serviceparameter enumeration that contains no supply chain value https://mysupplychain.dhl.com, read 2026-09-22: a login-gated React application whose page description reads "DHL MySC. Your one-stop-shop for supply chain data, insights and tools", served frommysupplychain.gocec.dhl.com- Live checks confirming
api-test.dhl.com/trackreturns HTTP 401 without a key, and DNS checks onmysupplychain.dhl.com,supplychain.dhl.com,api.dhl.comanddeveloper.dhl.com, run 2026-09-22 - Wikipedia, DHL Supply Chain, used only for the division's history, the 2005 Exel acquisition, the service list and the sector list, and explicitly not for scale figures
- /connectors/dhl, this catalogue's page on the DHL APIs that are public