Implementing the DCSA Commercial Schedules Standard

This is a guide to implementing the DCSA Commercial Schedules (CS) standard version 1.0, written for the technical teams of DCSA adopting organizations.

Reference Documentation

To get acquainted with the standard, refer to the introductory Commercial Schedules standard page.To understand the key concepts, user stories, use cases and data overview of the standard, refer to the Commercial Schedules documentation page.For an overview of the business processes addressed by the standard, refer to the DCSA Industry Blueprint.To understand the data structures used by the standard and how they can be mapped to your own organization's data types, consult the Commercial Schedules model in version 2024.Q4 of the DCSA Information Model.

Implementing the Standard

To get acquainted with the general principles applicable when implementing any DCSA standard, consult the DCSA API Design and Implementation Principles.To review the reference implementation of the Commercial Schedules standard, created by DCSA to verify the standard and used for measuring the conformance of adopter implementations, consult the Commercial Schedules module of the DCSA conformance GitHub repository.
Schedule Publisher Implementation
To implement the Commercial Schedules standard API as a schedule publisher, use your organization's technology stack to implement each endpoint of the DCSA Commercial Schedules OpenAPI specification page.
Schedule Consumer Implementation
To consume schedules published by any provider through the DCSA Commercial Schedules standard API, use your organization's technology stack to build a backend API client application using the DCSA Commercial Schedules OpenAPI specification page.As an alternative, you can also use directly the corresponding API specification page of one of the publishing organizations whose schedules you intend to retrieve through the DCSA standard API.👉Important note: While implementing the standard, run conformance periodically and use the Conformance Tool as a compass to guide the implementation. Don't wait until implementation has been finished and then run Conformance.

Version

List of changes and the version they are released in

Version

Date of Publication

Change

Purpose of change

1.0.2

13 February 2026

Point-to-Point routings

Add transportCallReference to departure.

Add transportCallReference to arrival.

This will help consumers better identify arrivals and departures in the provided legs.

1.0.2

13 February 2026

Point-to-Point routings

Add an object to support sharing the emissions footprint per leg and solution

This helps consumers assess routing options when footprint is a criterion for their choice.

1.0.2

13 February 2026

Point-to-Point routings

Add a cut-offs object in the legs to support sharing leg-specific cut-offs.

This helps carriers share cut-off information for legs that are not the first maritime leg with consumers, when available.

1.0.2

13 February 2026

Remove empty parameters on the endPoint root level

Fix bug

1.0.2

13 February 2026

Don't refer to the DCSA errorCode page, the API implementor maintains the codes returned.

Fix bug

1.0.2

13 February 2026

Update the description of the timestamp to align with other standards

Align with current standards, API design principles, and guidelines.

1.0.2

13 February 2026

Add a new optional field facilityName in Location objects.

Allow parties to specify facilities which are not identified by an SMDG / BIC code.

1.0.2

13 February 2026

Added a new optional field addressLines in the Address object.

Allow to capture unstructured address lines, used as a fallback when structured address fields are unavailable.

1.0.2

13 February 2026

Next-Page-Cursor, as defined, is impossible to comply with and is considered a bug to fix. Going forward, any filter parameters must be provided alongside the cursor parameter (this aligns with how it is done in AN (Arrival Notice))

Fix bug

1.0.1

25 April 2025

Added a new optional property routingReference (Routing reference) in the point-to-point API response endpoint. 

This will allow customers who integrate with the DCSA Booking API and Commercial Schedules API (point-to-point) to place a booking request with a specific routing previously fetched from Commercial Schedules, so that the booking will be created with the exact routing they need, without spending extra time re-keying information (such as vessel and service name) or on booking amendments due to routing discrepancies.