DSV Folds DB Schenker's API and EDI Into MyDSV

If you run EDI or API traffic into DB Schenker, the systems on the other end of that connection are being renamed, re-hosted, and rushed onto a faster clock than anyone expected. In early February 2026, DSV announced that the full integration of DB Schenker into DSV's platform will be complete by the end of 2026, roughly two years earlier than the original plan. For any shipper with a live Schenker EDI mailbox or API credential, this is not a background corporate story. It's a DSV Schenker API migration with a hard deadline, and your integration team needs a plan before your country's cutover lands.

What actually changed, and when

DSV completed its €14.3 billion acquisition of Schenker in April 2025, and the two companies started merging systems almost immediately. The customer-facing consequence is already visible if you've tried to log into Schenker's self-service tools recently: dbschenker.com has been merged into DSV.com, and Schenker Connect has been renamed and folded into a single portal, myDSV. During the transition, DSV is running two parallel login paths depending on which system your account originated from, one for legacy myDSV users and one for legacy DB Schenker Connect users. That split login is a visible symptom of a much bigger back-end consolidation touching booking, tracking, invoicing, and the EDI/API layers underneath.

Why the timeline just got shorter

This is the part that should worry integration teams more than the rebranding. DSV originally told the market that the majority of the Schenker integration would run through 2028. That changed in February 2026, when DSV said the process will be completed by the end of 2026, just 20 months after the acquisition closed, bringing the timeline forward by around two years compared with the original roadmap. DSV had already completed 30% of the structural integration by the end of 2025, twice the pace it had originally forecast, according to its own reporting.

Computer Weekly's reporting on the acquisition adds useful context on why the pace picked up: DSV is rushing to integrate Schenker's global operations at "unprecedented speed" to cut cost, simplify overly complex IT systems inherited from the merger, and start repaying the debt it raised to fund the deal. That's a finance-driven timeline, not an engineering-driven one, and it's exactly the kind of pressure that produces rushed cutovers, skipped regression testing, and endpoints that move faster than anyone documents them.

Country rollout: the dates that matter to you

What EDI users need to check first

Schenker's EDIFACT traffic has run on Axway B2B Integration for more than two decades, and it isn't a small setup. Axway's own case study quotes DB Schenker's Joachim Weise saying the company leverages over 10,000 EDI integrations to transport over a billion messages a year. That platform has been mid-migration to a load-balanced cloud architecture even before DSV entered the picture, moving from on-premises Oracle Solaris infrastructure to a multicluster AWS environment. As DSV folds this stack into its own systems on a compressed timeline, that migration work doesn't pause, it accelerates alongside everything else.

If you exchange IFTMIN, IFTSTA, or INVOIC messages with Schenker, don't assume your VAN, AS2 endpoint, or partner ID stays static through 2026. Concretely:

• Request written confirmation from your Schenker account manager of your specific country's cutover window, not a group-wide date.
• Ask whether your existing IFTMIN/IFTSTA message specs, reference qualifiers, and certification status carry over unchanged or require re-testing.
• Confirm your AS2 or VAN routing details in writing before, not after, your country moves.
• Keep a fallback contact for EDI support during the cutover window, since support teams are themselves being reorganised.

What API users need to check first

DSV runs its API program through a central DSV developer portal, where you register apps, pick up OAuth 2.0 subscription keys, and test in a sandbox before going live. As DSV centralizes Schenker's customer connectivity into this single catalogue, don't assume a lift-and-shift of old Schenker API credentials into the DSV developer portal. Re-register your applications, re-run your OAuth token flows in the sandbox, and re-test booking, label, and tracking calls end to end before you switch production traffic over. Treat each country cutover as a mini go-live, not a routine credential swap.

The bigger pattern shippers should plan for

DSV-Schenker is a large, visible example of a risk every shipper running direct carrier connections eventually faces: when two carriers or forwarders merge, their EDI and API stacks merge too, on a timeline you don't control and often don't hear about until your test calls start failing. Shippers who run TMS platforms with carrier connectivity built and maintained on their behalf, whether that's Cargoson, nShift, Shiptify, or FreightPOP, absorb this kind of endpoint churn on the vendor side. Shippers maintaining point-to-point Schenker connections themselves absorb it directly, and DSV's compressed schedule means that absorption is happening now, not gradually. The same dynamic plays out whenever consolidation reshuffles integration maps, whether through MercuryGate, Descartes, Transporeon, Alpega, Oracle TM, SAP TM, or Blue Yonder ecosystems.

Whatever happens with the next carrier merger, the practical step is the same one you should be doing right now for Schenker: build a full inventory of every live carrier connection by country, contract, and endpoint, not just by carrier name. That inventory is what turns a surprise cutover date into a manageable line item on your integration roadmap.