Implementing the DCSA Operational Vessel Schedules Standard

This is a guide to implementing the DCSA Operational Vessel Schedules (OVS) standard version 3.0, written for the technical teams of DCSA adopting organizations.

Reference Documentation

To get acquainted with the standard, refer to the introductory Operational Vessel Schedules standard page.To understand the key concepts, user stories, use cases and data overview of the standard, refer to the Operational Vessel 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 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 Operational Vessel Schedules standard, created by DCSA to verify the standard and used for measuring the conformance of adopter implementations, consult the Operational Vessel Schedules module of the DCSA conformance GitHub repository.
Schedule Publisher Implementation
To implement the Operational Vessel Schedules standard API as a schedule publisher, use your organization's technology stack to implement each endpoint of the DCSA Operational Vessel Schedules OpenAPI specification page.
Schedule Consumer Implementation
To consume schedules published by any provider through the DCSA Operational Vessel Schedules standard API, use your organization's technology stack to build a backend API client application using the DCSA Operational Vessel Schedules OpenAPI specification page.You can use a DCSA conformance sandbox as a counterpart in your development, since it allows you to easily test the most relevant scenarios that your application needs to support.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 overview

List of changes and the version they are released in

Version

Date of Publication

Change

Purpose of change

3.0.2

12 June 2026

Add facilityTypeCode to timestamps to support ETA Pilot Boarding Place

This change enables carriers to include ETA Pilot Boarding Place in OVS by adding facilityTypeCode to the timestamp object. Timestamps can then be qualified as BRTH for berth or PBPL for pilot boarding place, with BRTH as the default when omitted to preserve backward compatibility. This allows ETA PBP to be exchanged together with the relevant vessel schedule and terminal call information, avoiding the need for a separate API.

3.0.2

12 June 2026

Add an 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 Service 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.

3.0.1

14 November 2025

Added property delayReasonCodes to support Multiple Delay Reasons per timestamp. This property takes precedence over delayReasonCode (if both are present - only the ones provided in delayReasonCodes property are used).

Deprecated delayReasonCode from 3.0.1 onward.

This allows OVS implementers to submit multiple delay reasons for a timestamp to reflect real-world situations where multiple causes apply.

3.0.1

14 November 2025

Added property statusCodes to support multiple status codes per transport call. This property takes precedence over statusCode (if both are present - only the ones provided in statusCodes property are used).

This property also supports the codes: DRYD (Dry Dock), BUNK (Bunkering), OOSV (Out of service)

Deprecated statusCode from 3.0.1 onward.

This allows OVS implementers to submit multiple statuses for a transport call to reflect real-world situations where multiple statuses apply.

3.0.1

14 November 2025

The API specification includes a recommendation to follow for the naming of dummy vessels.

Applies to properties: vesselName, isDummyVessel

This allows carriers to distinguish between dummy vessels in the same schedule.

3.0.1

14 November 2025

Relax Import Voyage Number constraint by defining a no voyage number value = 9999R.

This allows carriers to provide a “no voyage number” import voyage number in edge cases (e.g., dry dock), without failing validation.

3.0.1

14 November 2025

The API specification includes more detail in the property eventClassifierCode for clarification of classifier use, which remains aligned with the OVS Definitions document.

Give further guidance in the API on when to send planned, estimated, and actual timestamps and semantics so the user can align expectations with partners.

3.0.1

14 November 2025

Added MMSINumber property as a query parameter and an optional property in the payload.

This allows carriers to provide an MMSI number when available when an IMO is or not available.

3.0.1

14 November 2025

Added vesselOperatorSMDGLinerCode as an optional filter

This allows filtering schedules' requests based on the vessel operator SMDG liner code.

3.0.1

14 November 2025

Adjusted pagination

Specified what limit does and added the Next-Page-Cursor header for the next page.