DCSA Standards Public Reference / Standards / Releases / Booking / Archive / Booking v2.0.4
DCSA BKG 2.0.4 - Conformance Scenarios
Archived release: Booking v2.0.4 has been superseded. View the current v2 documentation.
Contents
- Applicability
- What is conformance?
- Conformance criteria
- Conformance scenarios
- Conformance validations
Applicability
The source conformance document covers the DCSA Booking 2.x API and currently records Booking API version 2.0.4 as its applicable version. Its document revision date is July 27, 2026; the Carrier and Shipper validation workbook revisions are dated July 20, 2026.
What is conformance?
Conformance is the validation process used to assess whether an adopter’s implementation of the DCSA Booking API adheres to the expected technical and business requirements defined by DCSA. Its objective is to ensure interoperability across adopters and systems by demonstrating that APIs behave correctly in realistic, standards-based scenarios.
These conformance scenarios define the certification test set for Booking interoperability. They do not necessarily exercise every obligation in the standard specification exhaustively.
Conformance testing validates the minimum interoperability requirements exercised by the certification scenarios. Optional enrichments, implementation-specific extensions, and broader semantic completeness beyond the tested scenarios are out of scope.
Conformance criteria
Two conformance certification badges are available, one for each standard role:
- Carrier
- Shipper
To receive a badge, adopters implementing either role must support the required Booking capabilities for that role.
| Standard role | Business type (example) | Mandatory features to get a badge | Optional features | Scope qualifiers |
|---|---|---|---|---|
| Carrier | Ocean Carrier | Receive a Booking request through POST /v2/bookings.Return the content of a confirmed Booking through GET /v2/bookings/{bookingReference}.Receive a Booking update request or a Booking amendment request through PUT /v2/bookings/{bookingReference}. | Receive a cancellation for a Booking request, confirmed Booking, or Booking amendment through PATCH /v2/bookings/{bookingReference}.Request a Booking update or amendment. Reject a Booking request. Decline or complete a confirmed Booking. Send a Booking notification through POST /v2/booking-notifications implemented by the Shipper. | Cargo type: Dry, Reefer, DG |
| Shipper | Freight Forwarder / Shipper | Submit a Booking request through POST /v2/bookings implemented by the Carrier.Submit a Booking update and a Booking amendment request through PUT /v2/bookings/{bookingReference} implemented by the Carrier.Retrieve a Booking through GET /v2/bookings/{bookingReference} implemented by the Carrier. | Request cancellation of a Booking request, confirmed Booking, or Booking amendment through PATCH /v2/bookings/{bookingReference} implemented by the Carrier.Receive Booking notifications from the Carrier through POST /v2/booking-notifications. | Cargo type: Dry, Reefer, DG |
The standard role is the role for which the criteria are defined. Unless explicitly stated otherwise, the same criteria apply to all adopters implementing that role, regardless of business type.
The business type is an illustrative example of an adopter that may implement the standard role. It helps readers understand which organizations may implement a role but does not change the certification logic.
The mandatory features are the features an adopter implementing a role must support to be certified as conformant. Unless otherwise specified, all listed mandatory features must be implemented. A criterion may define a minimum subset, such as requiring at least one of two capabilities.
The optional features are meaningful capabilities that can be demonstrated and recorded in the certification details but do not determine badge eligibility.
The scope qualifiers identify the supported subset of the standard. An adopter may be certified for correctly implementing the mandatory features while the certification records the specific cargo type or other scope covered.
Conformance scenarios
The scenarios are organized into Carrier scenarios and Shipper scenarios.
- Carrier scenarios measure adopters implementing POST
/v2/bookings, PUT/v2/bookings/{bookingReference}, GET/v2/bookings/{bookingReference}, and PATCH/v2/bookings/{bookingReference}. Carriers may additionally send full or lightweight notifications through POST/v2/booking-notificationsimplemented by the Shipper. - Shipper scenarios measure adopters that submit Booking requests, updates or amendments, cancel and retrieve Bookings from a Carrier through the same endpoints. Shippers may additionally implement POST
/v2/booking-notificationsto receive notifications from the Carrier.
All performed scenarios and validation results form part of the conformance report, whether required or optional. All required scenarios must be completed for at least one scope qualifier—Dry, Reefer, or Dangerous Goods—to obtain a conformance badge. The same required scenarios must be completed for each additional qualifier claimed.
SupplyCSP prompts the Carrier to provide the sandbox with the relevant Booking data for a scenario, such as data qualifying as Dry cargo.
GET BKG is the default GET /v2/bookings/{bookingReference} action that retrieves the Booking request or latest confirmed Booking.
GET BKG (amended content) retrieves the amended Booking by setting the amendedContent=true query parameter.
Carrier conformance scenarios
Required Dry Cargo scenario
| Scenario | Purpose |
|---|---|
| SupplyCSP [Dry cargo] - UC1 - UC5 - GET BKG (CONFIRMED) | Verifies that the Carrier can accept a Booking request for Dry cargo, confirm it, and return the content of the confirmed Booking. |
Additional required Dry Cargo scenarios
Execute at least one of these two scenarios.
| Scenario | Purpose |
|---|---|
| SupplyCSP [Dry cargo] - UC1 - UC3 (2xx) | Verifies that the Carrier can accept a Booking update request for Dry cargo. |
| SupplyCSP [Dry cargo] - UC1 - UC5 - UC7 (2xx) | Verifies that the Carrier can accept a Booking amendment request for Dry cargo. |
Required Reefer scenarios
Execute the required Dry Cargo scenario and at least one of the two additional required Dry Cargo scenarios with Reefer cargo instead of Dry cargo.
Required Dangerous Goods scenarios
Execute the required Dry Cargo scenario and at least one of the two additional required Dry Cargo scenarios with Dangerous Goods cargo instead of Dry cargo.
Optional Carrier scenarios
| Scenario | Purpose |
|---|---|
| SupplyCSP [any BKG] - UC1 (2xx) - GET BKG (RECEIVED) | Verifies that the Carrier can return the content of a Booking request. |
| SupplyCSP [any BKG] - UC1 - UC2 - GET BKG (PENDING_UPDATE) | Verifies that the Carrier can request an update to a Booking request. |
| SupplyCSP [any BKG] - UC1 - UC4 - GET BKG (REJECTED) | Verifies that the Carrier can reject a Booking request. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC6 - GET BKG (PENDING_AMENDMENT) | Verifies that the Carrier can request an amendment to a confirmed Booking. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC7 - UC8 (confirm) - GET BKG (CONFIRMED) | Verifies that the Carrier can confirm a Booking amendment. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC7 - UC8 (decline) - GET BKG (CONFIRMED) | Verifies that the Carrier can decline a Booking amendment. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC7 (2xx) - GET BKG (amended content) (AMENDMENT_RECEIVED) | Verifies that the Carrier can return amended Booking content. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC7 - UC9 (2xx) - GET BKG (CONFIRMED) | Verifies that the Carrier can accept cancellation of a Booking amendment. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC10 - GET BKG (DECLINED) | Verifies that the Carrier can decline a confirmed Booking. |
| SupplyCSP [any BKG] - UC1 - UC11 (2xx) - GET BKG (CANCELLED) | Verifies that the Carrier can process cancellation of a Booking request. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC12 - GET BKG (COMPLETED) | Verifies that the Carrier can complete a confirmed Booking. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC13 (2xx) - GET BKG (CONFIRMED) | Verifies that the Carrier can accept a cancellation request for a confirmed Booking. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC13 - UC14 (confirm) - GET BKG (CANCELLED) | Verifies that the Carrier can confirm cancellation of a confirmed Booking. |
| SupplyCSP [any BKG] - UC1 - UC5 - UC13 - UC14 (decline) - GET BKG (CONFIRMED) | Verifies that the Carrier can decline cancellation of a confirmed Booking. |
Booking notifications are checked by verifying the presence and conformance of at least one notification sent by the Carrier in any executed scenario above.
Shipper conformance scenarios
Required Dry Cargo scenarios
| Scenario | Purpose |
|---|---|
| UC1 - GET BKG | Verifies that the Shipper can submit and retrieve a Booking request. |
| UC1 - UC2 - UC3 | Verifies that the Shipper can submit a Booking update when the Carrier requests an update. |
| UC1 - UC5 - UC6 - UC7 | Verifies that the Shipper can submit a Booking amendment when the Carrier requests an amendment. |
Required Reefer scenarios
Execute the required Dry Cargo scenarios with Reefer cargo instead of Dry cargo.
Required Dangerous Goods scenarios
Execute the required Dry Cargo scenarios with Dangerous Goods cargo instead of Dry cargo.
Optional Shipper scenarios
| Scenario | Purpose |
|---|---|
| UC1 - UC5 - UC7 - GET BKG (amended content) | Verifies that the Shipper can retrieve amended Booking content. |
| UC1 - UC5 - UC7 - UC9 | Verifies that the Shipper can request cancellation of a Booking amendment. |
| UC1 - UC5 - UC13 | Verifies that the Shipper can request cancellation of a confirmed Booking. |
| UC1 - UC11 | Verifies that the Shipper can cancel a Booking request. |
Booking notifications are checked by verifying the correct API response to at least one notification received in any executed scenario above.
Conformance validations
Conformance validations are specific to each role. Scope-defined and Carrier validations apply to everything the Carrier returns. Scope-defined and Shipper validations apply to everything the Shipper submits.
Conformance reports indicate whether validations succeeded or failed. All performed scenarios and validation results form part of the report, whether required or optional.
- Default validations: URL, response-code, and schema checks included in all communication between the sandbox and the testing party.
- Scope-defined validations: requirements imposed by the scope tested in a scenario.
- Carrier validations: standard-defined rules applied when a Carrier returns a Booking in response to a GET request.
- Shipper validations: standard-defined rules applied when a Shipper submits a Booking request, update, amendment, or cancellation request.
- Booking notification validations: standard-defined rules applied to Booking notifications. Notification support is optional and does not affect badge eligibility; when demonstrated, its results are included in the conformance report.
Scope-defined validations
Each scenario is seeded from a dedicated Booking payload and enforces these requirements in addition to the Carrier and Shipper validations.
| Scope | Mandatory requirements |
|---|---|
| Dry cargo | activeReeferSettings must not be present in any requestedEquipments item. isNonOperatingReefer must either be omitted or set to false. dangerousGoods must not be present in requestedEquipments.commodities.outerPackaging. |
| Reefer containers | At least one requestedEquipments item must contain activeReeferSettings. dangerousGoods must not be present in requestedEquipments.commodities.outerPackaging. |
| Dangerous goods | dangerousGoods must be present in requestedEquipments.commodities.outerPackaging. |
Carrier validations
Carrier validations apply when the Carrier returns a Booking in response to a GET request. The complete list is maintained in the Carrier Validations workbook. That workbook also includes validations applied when the Carrier sends Booking notifications. Where applicable, the scope-defined validations also apply to returned Bookings and notifications sent during the scenario.
Shipper validations
Shipper validations apply when the Shipper submits a Booking request, update, amendment, or cancellation request. The complete list is maintained in the Shipper Validations workbook. Where applicable, the scope-defined validations also apply to the Shipper payload for the scenario.