DSV API Integration: A Step-by-Step Setup Guide

Why DSV's API setup is confusing right now

If you're trying to connect your TMS or ERP to DSV right now, you're doing it in the middle of the largest freight forwarder merger in Europe. DSV closed its acquisition of Schenker on 30 April 2025, and the companies are still running on two sets of credentials while systems get stitched together. After DSV's acquisition of Schenker in April 2025 and the start of integration in various countries, from January 2026 the first entities in Germany are being legally merged, with further business units following in February 2026. More precisely, from January 1, 2026, DSV and Schenker officially operate under one flag in Road and Contract Logistics, with Air & Sea, Fairs & Events and customs following from February 1, 2026.

The practical fallout for integrators: you can log in to two versions of myDSV during the transition, and you choose the one that matches your existing account — myDSV for users who previously used myDSV, or myDSV (formerly DB Schenker Connect) for users who previously used DB Schenker Connect. This isn't a cosmetic rebrand. It determines which login screen you use, and it sits on top of a separate authentication layer in the Developer Portal that trips up almost everyone on their first integration. Let's get you through it in one pass.

What you need before you start

Before opening a browser tab, confirm three things: your DSV or Schenker customer agreement number, which transport mode you're integrating, and whether your team can handle SOAP as well as REST/OAuth2.

DSV splits its developer documentation by mode, and each guide uses a different auth pattern:

• Road (EU) booking runs through API - Road (SOAP), authenticated with a static subscription key.
• Air, Sea and Rail use REST endpoints, also authenticated with the static subscription key plus a myDSV access key in the body.
• XPress parcel services add two more headers on top of the subscription key: DSV-Service-Auth and the XPress Personal Access Token (x-pat), with login credentials selected by the user when signing up to the portal.
• Contract Logistics and the newer Generic/Warehousing APIs use OAuth 2.0, where you need myDSV credentials and your DSV-Subscription-Key to request an access token and refresh token from the token endpoint.

If you're only building one connection, pick the mode you actually ship through and ignore the rest. If you're building for a multi-modal relationship (Road plus Air & Sea, say), budget time for two different auth flows, not one.

Step-by-step: connecting to the DSV Booking API

This is the sequence that gets a Road booking working in DSV's demo environment, based on the Developer Portal's own guide and documented connection steps for the Booking API.

1. Confirm which myDSV account applies to your company. Check whether your contract originated with legacy DSV or legacy DB Schenker Connect, since customers may need to use one of two versions of myDSV depending on whether their account originated with DSV or with the former DB Schenker. Get this wrong and you'll be staring at a login screen that rejects credentials that are, in fact, valid — just for the other system.
2. Create a DSV Developer Portal account and sign in. This is a separate signup from myDSV itself.
3. Subscribe to the right product in the API Catalogue. Go to API CATALOGUE > API - ROAD (SOAP), select the Connect Booking API version, accept the Terms of Use, then click SUBSCRIBE.
4. Retrieve your subscription key. Go to Profile > Subscriptions and copy either the Primary key or the Secondary key. Either one works as your subscription key. Note that two keys are allocated per subscribed product, a "primary key" and a "secondary key," and only one key should be used in the HTTP header "DSV-Subscription-Key."
5. Register for myDSV access separately, and wait. Your access key identifies your DSV customer account, and DSV issues it only after the business team approves your registration. In practice you'll receive an email with the subject "myDSV's - Web Service Request" containing your access key. This approval step, not the portal signup, is usually what adds days to a project timeline.
6. Send your first request against the DEMO environment. This is where almost everyone stumbles the first time: the subscription key goes in the HTTP header, and the access key goes in the request body. Mixing up the two keys is the most common cause of authorization errors.
7. Validate the booking in the demo portal. Submitted test bookings should show up against your account so you can confirm the payload was parsed correctly before you build downstream logic on top of it.
8. Subscribe to webhook events for tracking and invoice updates. Once subscribed, DSV sends HTTPS POST notifications to your configured pushUrl whenever relevant events occur, e.g., Tracking, Invoice, Visibility, Quote, Warehousing, Customs Declaration, or API Downtime. This saves you from polling the Tracking API on a schedule.
9. Apply to go live, and swap credentials. Going to production means pointing requests at the production URL and changing the value of the HTTP header DSV-Subscription-Key to the new production API key, found on the Profile page, using fresh test credentials issued specifically for go-live.

How you know it worked

You'll know the integration is functioning when three things happen in sequence: a booking ID comes back from the API, a label PDF generates against that ID, and a webhook fires on status change.

Specifically: the Booking API should return a booking ID you can look up directly in myDSV. The Label Printing API should then return a usable PDF — printing of labels for submitted bookings is a distinct operation from booking itself, so test it separately rather than assuming a successful booking means labels will work too. Finally, send a test event through your webhook subscription and confirm your pushUrl endpoint actually receives the POST. If none of these three checks pass, don't move on to production credentials — you're debugging the wrong layer.

Common failure mode: mixing up the two keys (and the two logins)

The single most common integration bug with DSV is exactly the one DSV's own documentation warns about twice. Put the subscription key in the request body, or the access key in the header, and you'll get authentication failures that look like permissions problems but are actually just swapped credentials — confirmed directly in DSV's connection documentation: swapping the two keys is the most common cause of authorization errors.

The second failure mode is specific to the merger period: using legacy DB Schenker Connect credentials against the new DSV Developer Portal catalogue, or vice versa. Because the two versions of myDSV depend on whether your account originated with DSV or the former DB Schenker, your developer team might have the right subscription key but be pointing it at the wrong account context entirely.

The fix for both: keep a written credentials map per environment — subscription key goes in the header, access key goes in the body — and keep it separate for test versus production, since a credential pair (Access key and subscription key) matches the environment you connect to, because DSV issues separate credentials for testing and production. Don't let one developer carry this knowledge in their head; it needs to be documented where the next person on the project can find it.

If EDI is still your reality

Plenty of Schenker-heritage shippers never touch the API catalogue at all, because their production path is still EDIFACT. DB Schenker's EDI offering centers on four message types: IFTMIN S93A for booking shipments, IFTMCS S93A as a receipt and confirmation that the EDI was received, IFTSTA D96A for status observations such as the segment meaning "reading arrived at terminal," and INVOIC D93A for the invoice sent as EDIFACT.

Worth knowing for budget planning: public API and myDSV are offered to all customers free of charge, while EDI integrations come with a cost, and EDI Plus — a customized EDI integration — comes with a significantly higher price. If your finance team is comparing a REST/SOAP migration against staying on EDI, that cost delta is real and documented, not a sales pitch. Shippers who don't want to maintain raw EDIFACT parsing in-house often route it through bridging tools like Zenbridge, which translate EDI messages into a more modern API shape without forcing a renegotiation with the carrier.

Build it yourself vs. route it through a connectivity layer

A single DSV integration, done once, is a manageable two-week project for a competent developer. The problem is that DSV's two-key, two-portal pattern isn't unique to DSV — every carrier has its own version of this friction, and if you're running 10 to 30 carriers in parallel, you're maintaining 10 to 30 variations of this same credential dance, each with its own expiry policy, its own sandbox quirks, its own go-live approval process.

This is the reason unified carrier connectivity layers exist. Platforms like AfterShip, EasyPost, nShift and TMS systems such as Cargoson that build and maintain carrier connections directly already expose DSV, including DSV Road and DSV Air & Sea, through one normalized API and one credential set, so your team isn't relearning this pattern per carrier. For a single flagship carrier relationship, build it in-house. For a shipper juggling a few dozen, the math usually favors routing through a connectivity layer instead.

Closing / next steps

Nine steps get you from zero to a working DSV test booking: confirm your myDSV account type, create a Developer Portal account, subscribe to the right API product, grab your subscription key, register separately for myDSV access, fire your first demo request with the two keys in their correct places, validate in the demo portal, wire up webhooks, then go live. Most delays happen at step 5 (approval wait time) and step 6 (the key mix-up), so budget time accordingly and write your credential map down before a second developer touches the project.