This is a technical implementation guide to the DCSA electronic Bill of Lading (EBL) standard version 3.0. The audience of this document is technical teams of DCSA adopting organizations.

Table of Contents

Use Case 1: Submit Shipping Instructions

Use Case 2: Request to update Shipping Instructions

Use Case 3: Submit updated Shipping Instructions

Use Case 4: Process updated Shipping Instructions

Use Case 5: Cancel update to Shipping Instructions

Use Case 6: Publish Draft Transport Document

Use Case 7: Approve Draft Transport Document

Use Case 8: Issue Transport Document

Use Case 9: Request surrender Transport Document (amendment)

Use Case 10: Process Transport Document surrender request (amendment)

Use Case 11: Void original Transport Document and issue amended Transport Document

Use Case 12: Request surrender Transport Document (delivery)

Use Case 13: Process Transport Document surrender request (delivery)

Use Case 14: Confirm Shipping Instructions completed

Use Case 1: Submit Shipping Instructions

Synchronous carrier processing

• The shipper sends a POST request to create a Shipping Instructions.
• The Carrier MUST perform the schema validation, to ensure that if it accepts the Shipping Instructions it can subsequently return it as a valid GET response.
• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.
• If validations succeed, the Carrier responds with a 202 (Accepted) containing only the shippingInstructionsReference.
• The Shipping Instructions does not yet contain a state

GET (before Shipping Instructions is in state RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 202 (Accepted) / 404 (Not Found) / 409 (Conflict) without content.

GET updated Shipping Instructions - updatedContent=true (before Shipping Instructions is in state RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists.

GET Transport Document - (before Shipping Instructions is in state RECEIVED)

• The Shipper sends a GET Transport Document request to retrieve the Transport Document.
• The Carrier responds with 404 (Not Found) as no Transport Document exists.

Asynchronous carrier processing

• The Carrier continues validating and processing the Shipping Instructions, optionally collecting additional feedback.
• The Carrier sets the Shipping Instructions state to RECEIVED.
• The Carrier sends a Shipping Instructions Notification to the Shipper
  • If feedback was collected, it is included in the notification root
  • If a full notification is sent, the Shipping Instructions (shippingInstructions property) is included, also containing feedback
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions is in state RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • If feedback was collected, it is included in the Feedbacks property in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists.

GET Transport Document - (after Shipping Instructions is in state RECEIVED)

• The Shipper sends a GET Transport Document request to retrieve the Transport Document.
• If a Transport Document has previously been Drafted then the Carrier responds with a 200 (Ok) with the content of the Transport Document (or a 202 (Accepted) in case the Carrier is in the middle of processing the Transport Document).
• If no Transport Document yet exists - then the Carrier responds with 404 (Not Found).

Back to Table of Content ⬆️

Use Case 2: Request to update Shipping Instructions

• The Carrier changes the Shipping Instructions state to PENDING_UPDATE.
• The Carrier sends a notification to the Shipper.
  • There MUST be feedback, it is included in the notification root.
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, MUST also contain feedback.
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• If the Carrier performs Use Case 2 again or resends the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions is in state PENDING_UPDATE)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The mandatory feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state PENDING_UPDATE)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists after the status has changed to PENDING_UPDATE.

GET Transport Document - (after Shipping Instructions is in state PENDING_UPDATE)

• The Shipper sends a GET Transport Document request to retrieve the Transport Document.
• If a Transport Document has previously been Drafted then the Carrier responds with a 200 (Ok) with the content of the Transport Document (or a 202 (Accepted) in case the Carrier is in the middle of processing the Transport Document).
• If no Transport Document yet exists - then the Carrier responds with 404 (Not Found).

Use Case 3: Submit updated Shipping Instructions (synchronous carrier processing)

• The Shipper sends a PUT request to update a Shipping Instructions.
• The Carrier MUST perform the schema validation, to ensure that if it accepts the Shipping Instructions it can subsequently return it as a valid GET response.
• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.
• If validations succeed, the Carrier responds with an empty 202 (Accepted).
  • A 404 (Not Found) is returned if the carrierBookingRequestReference is not known.
  • A 409 (Conflict) is returned if the Carrier is processing a Shipping Instructions request.
• Shipping Instructions state is unchanged (it is still in RECEIVED or PENDING_UPDATE).

GET (Shipping Instructions is in state RECEIVED and updated Shipping Instructions is not yet in state UPDATE_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
  • Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET (Shipping Instructions is in state PENDING_UPDATE and updated Shipping Instructions is not yet in state UPDATE_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The mandatory feedback is included in the Shipping Instructions.
  • Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state RECEIVED or PENDING_UPDATE and before updated Shipping Instructions is in state UPDATE_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists after the status has changed to PENDING_UPDATE and before the update is in state UPDATE_RECEIVED.

GET Transport Document - (Shipping Instructions is in state RECEIVED or PENDING_UPDATE and before updated Shipping Instructions is in state UPDATE_RECEIVED)

• The Shipper sends a GET Transport Document request to retrieve the Transport Document.
• If a Transport Document has previously been Drafted then the Carrier responds with a 200 (Ok) with the content of the Transport Document (or a 202 (Accepted) in case the Carrier is in the middle of processing the Transport Document).
• If no Transport Document yet exists - then the Carrier responds with 404 (Not Found).

Use Case 3: Submit updated Shipping Instructions (asynchronous carrier processing)

• The Carrier sets the updated Shipping Instructions state to UPDATE_RECEIVED (the Shipping Instructions state is unchanged).
• The Carrier sends a notification to the Shipper.
  • If feedback for the updated Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent
    • The Shipping Instructions (Shipping Instructions property) is included, also containing feedback (mandatory if Shipping Instructions state is PENDING_UPDATE and optional if the Shipping Instructions state is RECEIVED)
    • The updated Shipping Instructions (Updated Shipping Instructions property) is included, optionally containing feedback
  • There MAY be differences between the feedback in the root and within the updated Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the updated Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after updated Shipping Instructions is in state UPDATE_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions (feedback is mandatory if the Shipping Instructions is in state `PENDING_UPDATE).
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after updated Shipping Instructions is in state UPDATE_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the updated Shipping Instructions).
  • The optional feedback MAY be included in the updated Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the updated Shipping Instructions asynchronously).

GET Transport Document - (Shipping Instructions is in state RECEIVED or PENDING_UPDATE and before updated Shipping Instructions is in state UPDATE_RECEIVED)

• The Shipper sends a GET Transport Document request to retrieve the Transport Document.
• If a Transport Document has previously been Drafted then the Carrier responds with a 200 (Ok) with the content of the Transport Document (or a 202 (Accepted) in case the Carrier is in the middle of processing the Transport Document).
• If no Transport Document yet exists - then the Carrier responds with 404 (Not Found).

Use Case 4: Process updated Shipping Instructions (confirm updated Shipping Instructions)

• The Carrier changes the Shipping Instructions state to RECEIVED.

• The Carrier changes the updated Shipping Instructions state to UPDATE_CONFIRMED.

• The update now becomes the confirmed Shipping Instructions (the Shipping Instructions property and the Updated Shipping Instructions property now contain the same value).

• The Carrier sends a notification to the Shipper.

  • If feedback for the Shipping Instructions is collected, it is included in the notification root
  • If a full notification is sent, the new Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the Shipping Instructions
  • If a full notification is sent, the update Shipping Instructions (Updated Shipping Instructions property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).

• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.

  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

• Use Case 4: Process updated Shipping Instructions (decline updated Shipping Instructions)

• The Carrier leaves the Shipping Instructions state unchanged (it can be RECEIVED or PENDING_UPDATE)

• The Carrier changes the updated Shipping Instructions state to UPDATE_DECLINED.

• The Carrier sends a notification to the Shipper.

  • If feedback for the Shipping Instructions is collected, it is included in the notification root
  • If a full notification is sent, the new Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the Shipping Instructions
  • If a full notification is sent, the update Shipping Instructions (Updated Shipping Instructions property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).

• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.

  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

xxx

• The Carrier changes the booking state to CONFIRMED.
• The Carrier changes the amended booking state to AMENDMENT_CONFIRMED.
• The amendment now becomes the confirmed booking (the booking property and the amendedBooking property now contain the same value). @george: maybe you have a better way of writing this?
• The Carrier sends a notification to the Shipper.
  • If feedback for the confirmed booking was collected, it is included in the notification root
  • If a full notification is sent, the newly confirmed booking (booking property) is included, also containing optional feedback connected to the confirmed booking
  • If a full notification is sent, the amendment (amendedBooking property) is included, also containing optional feedback connected to the amendment
  • There MAY be differences between the feedback in the root and within the confirmed booking (e.g. the Carrier MAY always include INFO feedback in the root but not within the booking, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

Use Case 4: Process updated Shipping Instructions (decline updated Shipping Instructions)

GET (after updated Shipping Instructions is in state AMENDMENT_CONFIRMED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after updated Shipping Instructions is in state AMENDMENT_CONFIRMED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.

• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

  • The optional feedback is included in the Shipping Instructions.

• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously). @george: not sure about the above sentence

• The Shipper sends a PUT request to update a Shipping Instructions.

• The Carrier MUST perform the schema validation, to ensure that if it accepts the Shipping Instructions it can subsequently return it as a valid GET response.

• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.

• If validations succeed, the Carrier responds with an empty 202 (Accepted).

  • A 404 (Not Found) is returned if the carrierBookingRequestReference is not known.
  • A 409 (Conflict) is returned if the Carrier is processing a Shipping Instructions request.

• Shipping Instructions state is unchanged (it is still in RECEIVED or PENDING_UPDATE).

• The Carrier changes the Shipping Instructions state to REJECTED.

• The Carrier sends a notification to the Shipper.

  • If feedback was collected, it is included in the notification root
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, also containing feedback
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).

• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.

  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions is in state REJECTED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state REJECTED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists before the Shipping Instructions is confirmed.

[Use Case 5: Confirm Shipping Instructions request](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc5-confirm-Shipping Instructions-request)

• The Carrier changes the Shipping Instructions state to CONFIRMED.
• The Carrier clears the amendedBooking state.
• The Carrier clears the bookingCancellation state.
• If it is a re-confirmation the Carrier clears the amendedBooking state and bookingCancellation state.
• The Carrier sends a notification to the Shipper.
  • If feedback was collected, it is included in the notification root
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, also containing feedback
  • If the Shipping Instructions is re-confirmed and a full notification is sent, the update (amendedBooking property) is cleared
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• If the Carrier performs Use Case 5 again or resends the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.
  • If the Shipping Instructions is re-confirmed and a full notification is sent, the update (amendedBooking property) is cleared

GET (after Shipping Instructions is in state CONFIRMED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state CONFIRMED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
  • If the Shipping Instructions was re-confirmed the Carrier responds with a 404 (Not Found)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

[Use Case 6: Request to amend confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc6-request-to-amend-confirmed-Shipping Instructions)

• The Carrier changes the Shipping Instructions state to PENDING_AMENDMENT.
• The Carrier clears the amendedBooking state.
• The Carrier clears the bookingCancellation state.
• The Carrier sends a notification to the Shipper.
  • There MUST be feedback, it is included in the notification root.
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, it MUST contain feedback.
  • If a full notification is sent, the update (amendedBooking property) is cleared.
  • There MAY be differences between the feedback in the root and within the Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• If the Carrier performs Use Case 6 again or resends the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions is in state PENDING_AMENDMENT)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The mandatory feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state PENDING_AMENDMENT)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as a possible update has been cleared.

[Use Case 7: Request update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc7-request-update-to-confirmed-Shipping Instructions) (synchronous carrier processing)

• The Shipper sends a PUT request to update a Shipping Instructions.
• The Carrier MUST perform the schema validation, to ensure that if it accepts the Shipping Instructions it can subsequently return it as a valid GET response.
• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.
• If validations succeed, the Carrier responds with an empty 202 (Accepted).
  • A 404 (Not Found) is returned if the carrierBookingReference is not known.
  • A 409 (Conflict) is returned if the Carrier is processing a Shipping Instructions request.
• Shipping Instructions state is unchanged (it is still in CONFIRMED or PENDING_AMENDMENT).
• The update state is unchanged (it is still in AMENDMENT_CONFIRMED, AMENDMENT_DECLINED or {empty} in case there is no ongoing update).

GET (Shipping Instructions is in state CONFIRMED and before it is in AMENDMENT_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (not the update) (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET (Shipping Instructions is in state PENDING_AMENDMENT and before it is in AMENDMENT_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (not the update) (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The mandatory feedback is included in the confirmed Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state CONFIRMED and before it is in AMENDMENT_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• If the confirmed Shipping Instructions is a result of an update (an update that has been confirmed via Use Case 8) or if the Carrier previously has declined an update to a confirmed Shipping Instructions - then the Carrier responds with 200 (Ok) with the content of the confirmed or declined update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed amended.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously). @george: not sure about the above sentence
• If the confirmed Shipping Instructions is a result of a re-confirmation - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state PENDING_AMENDMENT and before it is in AMENDMENT_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as there is no update.

[Use Case 7: Request update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc7-request-update-to-confirmed-Shipping Instructions) (asynchronous carrier processing)

• The Shipping Instructions state stays unchanged (CONFIRMED or PENDING_AMENDMENT).
• The Carrier changes the updated Shipping Instructions state to AMENDMENT_RECEIVED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the update was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the updated Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after updated Shipping Instructions is in state AMENDMENT_RECEIVED)

• The Shipper sends a GET request to retrieve the confirmed Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously). @george: not sure about the above sentence

GET updated Shipping Instructions - updatedContent=true (after updated Shipping Instructions is in state AMENDMENT_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the updated Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

[Use Case 8: Process update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc8-process-update-to-confirmed-Shipping Instructions) (Confirm update)

• The Carrier changes the Shipping Instructions state to CONFIRMED.
• The Carrier changes the updated Shipping Instructions state to AMENDMENT_CONFIRMED.
• The update now becomes the confirmed Shipping Instructions (the Shipping Instructions property and the amendedBooking property now contain the same value). @george: maybe you have a better way of writing this?
• The Carrier sends a notification to the Shipper.
  • If feedback for the confirmed Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent, the newly confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after updated Shipping Instructions is in state AMENDMENT_CONFIRMED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after updated Shipping Instructions is in state AMENDMENT_CONFIRMED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously). @george: not sure about the above sentence

[Use Case 8: Process update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc8-process-update-to-confirmed-Shipping Instructions) (Decline update)

• The Shipping Instructions state stays unchanged (CONFIRMED or PENDING_AMENDMENT).
• The Carrier changes the updated Shipping Instructions state to AMENDMENT_DECLINED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the confirmed Shipping Instructions was collected, it is included in the notification root @george: not sure about the above sentence... Should the feedback in the root be about the confirmed Shipping Instructions or the update?
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after updated Shipping Instructions is in state AMENDMENT_DECLINED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after updated Shipping Instructions is in state AMENDMENT_DECLINED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously). @george: not sure about the above sentence

[Use Case 9: Cancel update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc9-cancel-update-to-confirmed-Shipping Instructions) (synchronous carrier processing)

• The Shipper sends a PATCH request to cancel a Shipping Instructions update.
• The Carrier MUST perform the schema validation, to ensure that if it accepts the cancellation it can subsequently process it.
• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.
• If validations succeed, the Carrier responds with an empty 202 (Accepted).
  • A 404 (Not Found) is returned if the carrierBookingReference is not known.
  • A 409 (Conflict) is returned if the Carrier is processing a Shipping Instructions request.
• Shipping Instructions state is unchanged (it is still in CONFIRMED or PENDING_AMENDMENT).
• The update state is unchanged (it is still in AMENDMENT_RECEIVED).

GET (Shipping Instructions is in state CONFIRMED or PENDING_AMENDMENT and before it is in AMENDMENT_CANCELLED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state CONFIRMED or PENDING_AMENDMENT and before it is in AMENDMENT_CANCELLED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

[Use Case 9: Cancel update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc9-cancel-update-to-confirmed-Shipping Instructions) (asynchronous carrier processing accepting the cancellation)

• The Shipping Instructions state stays unchanged (CONFIRMED or PENDING_AMENDMENT).
• The Carrier changes the updated Shipping Instructions state to AMENDMENT_CANCELLED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the update was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the updated Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after updated Shipping Instructions is in state AMENDMENT_CANCELLED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after updated Shipping Instructions is in state AMENDMENT_CANCELLED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

[Use Case 9: Cancel update to confirmed Shipping Instructions](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc9-cancel-update-to-confirmed-Shipping Instructions) (asynchronous carrier processing decline the cancellation)

• The Shipping Instructions state stays unchanged (CONFIRMED or PENDING_AMENDMENT).
• The updated Shipping Instructions stays unchanged AMENDMENT_RECEIVED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the update was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the updated Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after amended cancellation is declined and updated Shipping Instructions is in state AMENDMENT_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after amended cancellation is declined and updated Shipping Instructions is in state AMENDMENT_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

[Use Case 10: Decline Shipping Instructions by Carrier](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc10-decline-Shipping Instructions-by-carrier)

• The Carrier changes the Shipping Instructions state to DECLINED.
• The Carrier changes the updated Shipping Instructions state to AMENDMENT_DECLINED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the declined Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions is in state DECLINED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state `DECLINED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).
• If the confirmed Shipping Instructions is a result of a re-confirmation or an update was never requested - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

[Use Case 11: Cancel Shipping Instructions request by Shipper](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc11-cancel-Shipping Instructions-request-by-shipper) (synchronous carrier processing)

• The Shipper sends a PATCH request to cancel a Shipping Instructions.
• The Carrier MUST perform the schema validation, to ensure that if it accepts the cancellation it can subsequently process it.
• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.
• If validations succeed, the Carrier responds with an empty 202 (Accepted).
  • A 404 (Not Found) is returned if the carrierBookingRequestReference is not known.
  • A 409 (Conflict) is returned if the Carrier is processing a Shipping Instructions request.
• Shipping Instructions state is unchanged (it is still in RECEIVED, PENDING_UPDATE or UPDATE_RECEIVED).

GET (Shipping Instructions is in state RECEIVED, PENDING_UPDATE or UPDATE_RECEIVED and before it is in state CANCELLED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the Shipping Instructions is in state PENDING_UPDATE - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state RECEIVED, PENDING_UPDATE or UPDATE_RECEIVED and before it is in state CANCELLED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists before the Shipping Instructions is confirmed.

[Use Case 11: Cancel Shipping Instructions request by Shipper](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc11-cancel-Shipping Instructions-request-by-shipper) (asynchronous carrier processing accepting cancellation)

• The Carrier changes the Shipping Instructions state to (CANCELLED).
• The Carrier sends a notification to the Shipper.
  • If feedback for the cancelled Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback (if the confirmed Shipping Instructions is in state PENDING_UPDATE - the feedback is mandatory)
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (Shipping Instructions is in state CANCELLED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state CANCELLED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists before the Shipping Instructions is confirmed.

[Use Case 11: Cancel Shipping Instructions request by Shipper](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc11-cancel-Shipping Instructions-request-by-shipper) (asynchronous carrier processing declining cancellation)

• The Shipping Instructions state stays unchanged (RECEIVED, PENDING_UPDATE or UPDATE_RECEIVED).
• The Carrier sends a notification to the Shipper.
  • If feedback for the declined cancellation was collected, it is included in the notification root
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback (if the confirmed Shipping Instructions is in state PENDING_UPDATE - the feedback is mandatory)
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (Shipping Instructions is in state RECEIVED, PENDING_UPDATE or UPDATE_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_UPDATE - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state RECEIVED, PENDING_UPDATE or UPDATE_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 404 (Not Found) as no update exists before the Shipping Instructions is confirmed.

[Use Case 12: Confirm Shipping Instructions completed](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc12-confirm-Shipping Instructions-completed)

• The Carrier changes the Shipping Instructions state to COMPLETED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the completed Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent, the Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions
  • If a full notification is sent, the update (amendedBooking property) is included, also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions is in state COMPLETED)

• The Shipper sends a GET request to retrieve the completed Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the completed Shipping Instructions
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions is in state COMPLETED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).
• If the completed Shipping Instructions is a result of a re-confirmation or an update was never requested - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

[Use Case 13: Cancel confirmed Shipping Instructions by Shipper](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc13-cancel-confirmed-Shipping Instructions-by-shipper) (synchronous carrier processing)

• The Shipper sends a PATCH request to cancel a confirmed Shipping Instructions.
• The Carrier MUST perform the schema validation, to ensure that if it accepts the cancellation it can subsequently process it.
• The Carrier MAY also perform other validations or processing synchronously, optionally resulting in the collection of feedback.
• If validations succeed, the Carrier responds with an empty 202 (Accepted).
  • A 404 (Not Found) is returned if the carrierBookingReference is not known.
  • A 409 (Conflict) is returned if the Carrier is processing a Shipping Instructions request.
• Shipping Instructions state is unchanged (it is still in CONFIRMED or PENDING_AMENDMENT
• updated Shipping Instructions state is unchanged (can be {any state}).

GET (Shipping Instructions is in state CONFIRMED or PENDING_AMENDMENT and before Shipping Instructions cancellation is in CANCELLATION_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (Shipping Instructions is in state CONFIRMED or PENDING_AMENDMENT and before Shipping Instructions cancellation is in CANCELLATION_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).
• If the confirmed Shipping Instructions is a result of a re-confirmation or an update was never requested - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

[Use Case 13: Cancel confirmed Shipping Instructions by Shipper](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc13-cancel-confirmed-Shipping Instructions-by-shipper) (asynchronous carrier processing)

• The Shipping Instructions state stays unchanged (CONFIRMED or PENDING_AMENDMENT).
• The updated Shipping Instructions state stays unchanged (can be {any state}).
• The Carrier changes the Shipping Instructions cancellation state to CANCELLATION_RECEIVED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the cancellation was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
  • If a full notification is sent, the update (amendedBooking property) is included (if it exists), also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions cancellation is in state CANCELLATION_RECEIVED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions cancellation is in state CANCELLATION_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).
• If the confirmed Shipping Instructions is a result of a re-confirmation or an update was never requested - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

[Use Case 14: Process Shipping Instructions cancellation](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc14-process-Shipping Instructions-cancellation) (confirm cancellation)

• The Carrier changes the Shipping Instructions state to CANCELLED.
• The Carrier changes the updated Shipping Instructions state to AMENDMENT_CANCELLED.
• The Carrier changes the Shipping Instructions cancellation state to CANCELLATION_CONFIRMED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the cancelled Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions
  • If a full notification is sent, the update (amendedBooking property) is included (if it exists), also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions cancellation is in state CANCELLATION_CONFIRMED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the cancelled Shipping Instructions
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions cancellation is in state CANCELLATION_RECEIVED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).
• If the confirmed Shipping Instructions is a result of a re-confirmation or an update was never requested - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

[Use Case 14: Process Shipping Instructions cancellation](https://dcsa.org/standards/Shipping Instructions/documentation-Shipping Instructions-2/Shipping Instructions-2-use-cases#uc14-process-Shipping Instructions-cancellation) (decline cancellation)

• The Shipping Instructions state stays unchanged (CONFIRMED or PENDING_AMENDMENT).
• The updated Shipping Instructions state stays unchanged (can be {any state}).
• The Carrier changes the Shipping Instructions cancellation state to CANCELLATION_DECLINED.
• The Carrier sends a notification to the Shipper.
  • If feedback for the confirmed Shipping Instructions was collected, it is included in the notification root
  • If a full notification is sent, the confirmed Shipping Instructions (Shipping Instructions property) is included, also containing optional feedback connected to the confirmed Shipping Instructions (if the confirmed Shipping Instructions is in state PENDING_AMENDMENT - the feedback is mandatory)
  • If a full notification is sent, the update (amendedBooking property) is included (if it exists), also containing optional feedback connected to the update
  • There MAY be differences between the feedback in the root and within the confirmed Shipping Instructions (e.g. the Carrier MAY always include INFO feedback in the root but not within the Shipping Instructions, or the other way around).
• The Carrier MAY resend the notification, a different notification id or previous notification id can be reused.
  • The content of the notification MAY be the same or different.
  • The feedback MAY be the same or different.

GET (after Shipping Instructions cancellation is in state CANCELLATION_DECLINED)

• The Shipper sends a GET request to retrieve the Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the confirmed Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).

GET updated Shipping Instructions - updatedContent=true (after Shipping Instructions cancellation is in state CANCELLATION_DECLINED)

• The Shipper sends a GET request with the updatedContent query parameter set to true to retrieve the updated Shipping Instructions.
• The Carrier responds with 200 (Ok) with the content of the updated Shipping Instructions (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).
  • The optional feedback is included in the Shipping Instructions.
• Subsequent GET requests MAY return different feedback (e.g. the Carrier MAY still be processing the Shipping Instructions asynchronously).
• If the confirmed Shipping Instructions is a result of a re-confirmation or an update was never requested - then the Carrier responds with 404 (Not Found) as there is no update (or a 202 (Accepted) / 409 (Conflict) in case the Carrier is in the middle of processing the Shipping Instructions).

Back to Table of Content ⬆️