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.3

12 June 2026

Vessel Schedules: Add optional responseScope query parameter to control whether full voyages or only matched transport calls are returned

This change enables API consumers to control whether the Vessel Schedules endpoint returns the full matched voyage or only the transport calls matching the query parameters. The optional parameter, responseScope, supports FULL_VOYAGE and MATCHED_CALLS. If omitted, the value must be interpreted as FULL_VOYAGE to preserve backward compatibility.

1.0.3

12 June 2026

Point-to-Point routings: Add co2e to solution and leg footprint objects

This change adds support for COâ‚‚ equivalent emissions by introducing a co2e property in the footprint objects at solution and leg level. It allows carriers to provide COâ‚‚e values in addition to existing COâ‚‚ values where available. The reported values represent total estimated emissions for the routing solution and/or individual legs, typically per TEU, not emissions intensity values such as per TEU-km.

1.0.3

12 June 2026

Point-to-Point routings: Add cargoType query filter

This change enables API consumers to request point-to-point routing solutions for a specific cargo type, initially DRY or REEFER. The cargo type may influence which routing solutions are returned, which transport legs are feasible, and which footprint values are reported.

1.0.3

12 June 2026

Point-to-Point routings: Add an intermediateCalls object within a Leg to group non-transhipment intermediate transport calls

This change enables grouping of intermediate non-transhipment transport calls within a leg, avoiding the need to represent each call as a separate leg. It addresses usability challenges faced by solution providers when consuming richer schedule data, allowing simplified UI presentation while preserving full operational detail and ensuring consistent comparability across carriers.

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.