Developer Guide - ROAD (V3)

On this page you will find an overview of the available APIs and the different options offered via each API next to a description of the involved authentication method used in the APIs.

API: Booking V3

Submit bookings to DSV via DSV’s Booking API V3.

1. Overview & API Scope

The Booking V3 API provides a standardized interface for integrating client software directly with DSV's operational systems.

  • Supported Transport Mode: Booking V3 currently supports Road transport bookings exclusively.

  • Final Booking Submission: Submitting a request creates a live, final booking directly in DSV's operational pipeline for immediate execution.

  • Unsupported Features: Draft bookings, automated cancellations, and the autobook flag are currently not supported in Booking V3.

2. Required Credentials & Environment Endpoints

Before sending your first booking request, ensure your integration has obtained the following credentials:

  1. DSV User Credentials: Credentials from myDSV Legacy, used to generate an OAuth 2.0 access token. The token must be passed in the HTTP header as Authorization: Bearer <access_token>.

  2. API Subscription Key: Your active subscription key assigned on the DSV Developer Portal, passed in the HTTP header (DSV-Subscription-Key).

  3. Developer Portal Account & API Credentials: Valid DSV API credentials and an active API subscription key obtained from your DSV Developer Portal Profile account is available, ensuring the correct DSV account and MDM numbers are used.

  4. Target Environment Endpoint: Always verify that you are sending API calls to the endpoint URL corresponding to your intended environment (QA / Testing vs. Production).

3. Mandatory Booking Addresses & Party Roles

To submit a road freight booking, your payload must include four mandatory booking address parties:

  • Ordering Party (orderingPayer): Mandatory. Represents the customer or orderer placing the transport order with DSV. Replaces prior Booking V2 conventions.

  • Freight Payer (freightPayer): Mandatory. The entity responsible for paying the transport and freight charges.

  • Sender / Consignor (sender): Mandatory. The origin party and address where cargo is picked up or dispatched from.

  • Receiver / Consignee (receiver): Mandatory. The destination party and address receiving the delivered cargo.

  • Booking Party (bookingParty): Optional. Used only when an external third party submits or handles the booking on behalf of the customer.

  • Pickup & Delivery (pickup / delivery): Optional. Used when physical pickup or delivery addresses differ from the Sender or Receiver address locations 

4.Ordering Party Address

For the current Booking V3 implementation, the full address details of the Ordering Party must be provided. Do not provide only an MDM number for the Ordering Party.

Example:

"orderingParty": {

  "address": {

    "name": "Example Company",

    "street": "Example Street 10",

    "city": "Copenhagen",

    "postalCode": "1000",

    "countryCode": "DK"

  }

}

5. Account Identifiers (MDM) & Address Formatting

  • DSV identifies customer accounts using Master Data Management (MDM) numbers. Your MDM account number connects your booking request to your configured account profile, rates, and billing structures.

  •   When an MDM number is provided in address.mdm, do not provide street, city, postal code, or other physical address details for the same address.

Note: For the Ordering Party, the full address is currently required.

6. Testing Setup & QA Environment

  • Testing Environment: There is currently no standalone Demo environment available. All integration testing is conducted in the QA environment.

  • Obtaining Test MDM Setup: To set up your QA test profile and obtain assigned test MDM account numbers, contact your DSV IT Team.

  • No Production Data in Testing: Never use Production customer MDM account numbers in QA testing to avoid populating live operational databases with test data.

_________________________________________________________________________________________________________

API: Label Printing V3

On this page, you will find an overview of the Label Printing API, detailing how to generate and download package shipping labels for your bookings.

API: Label Printing

Print package shipping labels (PDF) for bookings submitted via DSV’s Booking V3 API

Supported Transport Mode: Road

The Label Printing API offers one method to print package labels:

Download PDF Label(s) via Booking ID (GET /labels/{bookingid})

  • Feature: Download printable PDF package shipping labels directly via API for Road transport bookings submitted via the Booking V3 API or online via DSV’s myDSV customer portal.

  • Identifier: Uses the DSV Booking ID (e.g. 40257145990000123456) or SSCC ID provided in the booking confirmation.

_________________________________________________________________________________________________________

API: Tracking V3

Track the status and latest events of your shipments moved by DSV.

Supported transport mode: Road

1. Overview

The Tracking API V3 provides Road shipment tracking information using a revised structure aligned with Booking API V3. Existing tracking capabilities are retained, while request and response structures and field mappings have been updated.

Supported Transport Mode: Road exclusively.

A. Shipment List Endpoints (POST Methods)

Use these endpoints to search and retrieve lists of Road shipments based on specific filter criteria:

  • POST Shipment List: Retrieves a list of Road shipments using standard search criteria (e.g. status, mode).

Key Data Elements Returned: DSV Shipment ID, DSV Booking ID, TMS ID, Customer References, Address details, Transport mode (Road), Shipment Status, Pickup date/time, Delivery date/time.

B. Shipment Details Endpoints (GET Methods)

Use these endpoints to retrieve detailed shipment tracking data, milestone events, and location histories:

  • GET Shipment by Booking ID: Retrieves complete tracking details using the DSV Booking ID (e.g. 40257145990000123456) generated during Booking V3 creation.

  • GET Shipment by TMS ID: Retrieves detailed tracking data using the internal DSV Shipment / TMS ID (e.g. SCPH1234567, 10123456).

  • GET Shipment by Reference: Retrieves detailed tracking data using client Customer References (e.g. Consignor Reference, Consignee Reference, PO Number).

Key Data Elements Returned: DSV Shipment ID, DSV Booking ID, Booked By, Address details, Transport mode (Road), Shipment Status, Milestone Events, Pickup date/time, Delivery date/time.

_________________________________________________________________________________________________________

Login credentials for online portals 

When developing against the generic APIs, 2 online portals are made available for supporting the development process.  

  • DSV Developer portal 

    • Main portal for DSV’s APIs covering the API catalogue, technical documentation, developer guides and subscriptions for the different APIs. 

    • The API key (HTTP header: DSV-Subscription-Key) is found on the profile page of the portal. 

    • Login credentials are selected by the user when signing up to the portal. 

  • myDSV QA portal 

    • Online booking and tracking portal where bookings submitted via the test booking API is visible. It is recommended to use the demo portal to verify if the information submitted via the APIs are correctly received by DSV. 

    • Login credentials are provided via email shortly after the first subscription request is sent. Any additional subscription you request for the generic APIs will fall under the same set of credentials.

_________________________________________________________________________________________________________

Postman Collections

To facilitate easy development and testing Postman collections for each endpoint have been created: