Modify Booking
Overview
The Modify Booking method is designed for modifying various content exposed by Sabre. The current version supports modification of the following type of content:
- CSL hotel bookings
- Traditional content:
- group bookings
- ATPCO content (limited functionality)
This is achieved by executing internal calls to the individual product domains (PNR, Hotels) and then consolidating updated information into a single normalized response.
Technical overview
Modify Booking is available in RPC/JSON format. This API is designed to operate in a stateless way, and accepts both sessionless (ATK) and session-based (ATH) tokens. When a call is made to this API via a session-based token, the session (AAA) is cleared before and after execution.
General logic
Modify Booking contains internal logic that determines when to call specific downstream APIs based on request qualifiers. During the orchestration process, if a failure of a domain service call prevents the API from modifying a booking, the system will stop processing and pass an error.
This method allows executing multiple operation types such as addition, modification, and deletion at once, based on the information specified in the request:
before
is used to pass details regarding the original state of a chosen booking.after
is used to pass an expected state of the booking, after changes are applied.
Note: Modify Booking request has been designed based on the existing Get Booking and Create Booking structure, allowing users to easily construct desired modification instructions.
Prior to applying any changes to the booking Modify Booking verifies its current status based on the value specified under bookingSignature
property. This is a mandatory step and requires the user to execute Get Booking call to obtain this information.
The idea behind bookingSignature
property is to check if any unexpected updates have been made to the booking in the short timeframe, between the reading call (Get Booking) and the modification request (Modify Booking). This way API applies requested changes only if the user is working with up-to-date booking.
To ensure a smooth modification process it is essential to include valid information in the before
and after
properties. This way the application can recognize desired set of changes requested by the user and act accordingly.
Modify Booking has also automatic special service request (SSR) logic for infant travelers. When infant traveler information is modified the application automatically handles the creation of the associated INFT SSR.
Internal orchestration
The APIs orchestrated in Modify Booking include:
Supported operations
The capabilities in terms of updating information within a CSL booking using the Modify Booking method are:
Information | Addition | Modification | Deletion |
---|---|---|---|
flight arrival/departure details | Supported | Supported | Supported |
check-in/check-out date outside date range | N/A | Supported | N/A |
check-in/check-out date within date range | N/A | Supported | N/A |
corporate id number | Supported | Supported | Supported |
form of payment | Supported | Supported | N/A |
frequent traveler number | Supported | Supported | Supported |
guest loyalty id | Supported | Supported | Supported |
guest number | N/A | Supported | N/A |
IATA number | N/A | Supported | N/A |
lead guest | N/A | Supported | N/A |
special instructions | Supported | Supported | Supported |
room type | N/A | Supported | N/A |
Note Highlighted information in the above table requires a re-shop step. Use one of the CSL shopping APIs REST or SOAP, followed by Hotel Price Check REST or SOAP. Once you have a new booking key, use it in the Modify Booking.
Note Only previously committed and confirmed bookings can be changed.
The capabilities in terms of updating information within a traditional booking using the Modify Booking method are:
Information | Addition | Modification | Deletion |
---|---|---|---|
traveler details | N/A | Supported | N/A |
traveler details - group bookings | Supported | Supported | Supported |
associated phones/emails | Supported | Supported | Supported |
frequent traveler number | Supported | Supported | Supported |
identity documents | Supported | Supported | Supported |
travel agency customer identifier (DK number) | Supported | Supported | N/A |
special services | Supported | Supported | Supported |
Note Modification of the highlighted details in the above table may be limited due to airline policies.
Limitations
The CSL hotel content:
- Modification of the hotel bookings containing child or infant guests is currently not supported.
- At the moment, changing the form of payment to a virtual payment is restricted.
- Only payment card information is saved after booking modification when used as a desired hotel payment type. The remaining hotel-supported forms of payment are passed to the hotel vendor "on the fly."
Modify Booking request structure
Modify Booking method can be used to add, modify, or delete information stored in an existing booking. To successfully apply indicated changes by the user, mandatory elements should be included in the request:
-
bookingSignature
the unique identifier of a booking (obtained using the Get Booking method). It is used to verify the state of the booking prior to a modification operation. -
confirmationId
represents the booking reference ID as shown in the source supplier/vendor system. For SABRE, this is the PNR Record Locator (RECLOC) value.
Note: Modify Booking currently supports PNRs that contain CSL bookings only.
-
before
contains the original booking details that were present before the desired modification operation. -
after
contains the desired booking details due to the finalized modification operation.
Due to the fact that Modify Booking has a structure based on the other BM API methods, the user may recycle the majority of the elements from Get Booking response; for e.g., travelers
property can be copied/pasted with all the details. Alternatively, the user can adjust the Modify Booking request to minimize its size and keep only those properties that are currently supported.
Note: Refer to the "Reference documentation" section to check the current structure of the Modify Booking method.
The remaining elements are optional and allow for more granular control of the call:
-
retrieveBooking
is an optional element that specifies if full booking details should be included in the response. -
receivedFrom
is an optional property that passes information on the entity that authorized the creation of the booking. -
targetPcc
changes the context to a desired pseudo city code. This is particularly useful for agencies that separate their booking flow across different pseudo city codes (PCCs).
Modify Booking response structure
Modify Booking response is mainly composed of the response structure found in Get Booking and contains details of the modified booking.
-
booking
contains the details of the booking. Refer to the Get Booking section for detailed information. -
errors
includes all errors returned by the API. This array will not display in successful responses. -
request
includes a copy of the request sent to the API.
Error handling
This section illustrates the current error handling logic for Modify Booking:
Error structure
Field | Type | Description |
---|---|---|
category | String | Indicates error category. |
description | String | Provides detailed description. |
type | String | Indicates error type. |
fieldPath | String | Request’s field path if error caused by bad request. |
fieldName | String | Request’s field name if error caused by bad request. |
fieldValue | String | Request’s field value if error caused by bad request. |
Error codes
If an error(s) occurs, Modify Booking returns a non-empty errors
list. Each item in the collection contains three fields with possible values:
-
type
-
category
-
description
Note: Refer to the Modify Booking - Error List section for additional details on possible errors returned by Modify Booking.