The Get Booking method is designed to provide a normalized view of a Sabre reservation by combining both the Sabre PNR and the Sabre Order (see New Distribution Capability) views within a single response.
This is achieved by executing internal calls to the individual product domains (PNR & Order) and then consolidating the information into a single normalized response.
Additionally, this API sources extra content from other internal Sabre domains (Ticketing, Pricing) to provide a more holistic view of the Sabre reservation to better support traveler-oriented use cases. For example, "Can I change my ticket?"
Get Booking is available in RPC/JSON and GraphQL formats. 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.
Independent of the desired way to consume the Get Booking API (RPC or GraphQL), the underlying implementations are very similar and are described further in the sections below.
Note: Due to low interest, the GraphQL format of this API is set for retirement.
Get Booking contains internal logic that determines when to call specific downstream APIs based on request qualifiers or the content present in the Sabre reservation.
Example: If no tickets are present within a reservation, the API will not make an additional call to the Ticket Display API.
The APIs orchestrated in Get Booking include:
- Order Management
The RPC/JSON format follows the same pattern as other REST APIs in the Sabre portfolio, allowing users to either retrieve the reservation:
- In full
- Via a pre-defined set of subsections of the reservation (flights, hotels, penalties, remarks, etc.), ensuring flexibility for your application.
GraphQL (set for retirement)
The GraphQL format allows you to define individual data elements to retrieve from the full API schema. For example, you can opt to only return the traveler’s name, trip start date, and tickets.
This is one of the first Sabre APIs to be exposed in GraphQL format, and is currently exposed as an initial beta version.
Note: Refer to Get Booking - GraphQL (Beta) for more.
Get Booking request structure
The Get Booking method can be used to display previously created reservations. There's only one mandatory element in the request structure, which is the unique
id of the reservation to display.
The remaining elements are optional and allow for more granular control of the response:
confirmationIdrepresents the booking reference ID as shown in the source supplier/vendor system. For SABRE, this is the PNR Record Locator (RECLOC) value or Sabre Order ID.
bookingSourceis an optional element that specifies the source of booking. Defaults to SABRE.
givenNameis the traveler’s first name (optional).
middleNameis the traveler’s middle initial (optional).
surnameis the traveler’s last name (optional).
These data elements (
surname) have been introduced to perform an extra security validation step when retrieving a reservation, ensuring the traveler data provided matches with the provided Confirmation ID.
returnOnlyis an optional list of segments returned only in a service response. If this list is empty or is not provided at all, the full structure is returned.
returnOnlyoption may cause the application to exclude or simplify calls of downline APIs, which usually results in a significant performance boost.
unmaskPaymentCardNumbersis an option to unmask payment card information stored in the booking if set to true.
unmaskPaymentCardNumbersoption works only if the Employee Profile Record (EPR) includes the CCVIEW keyword. For more information contact your Account Representative.
Get Booking response structure
The Get Booking response structure is composed of an orchestration of different Sabre API calls to provide a comprehensive view of the Sabre booking (refer to Internal Orchestration for additional references).
Note: The list of APIs orchestrated by Get Booking is expected to grow/evolve as we continue iterating on the design.
All APIs in the orchestration are not called upon every execution of a Get Booking request. Internal logic is in place to determine in which case to call each API. For example, when there is no Sabre NDC Order content, Get Booking does not call the Order Management API.
Additionally, you may encounter that two or more orchestrated APIs reference the same data elements. In these cases, there is pre-defined priority logic to ensure we always prioritize Sabre Order data over Sabre PNR data. The traveler’s phone number is a good example of this, as it is likely available in both data structures.
Below is a list of some of the most relevant elements that are part of a Get Booking call (the full list is available in the Reference tab of this API):
startDate: The start date of the booking in ISO 8601 format.
endDate: The end date of the booking in ISO 8601 format.
isCancelable: If true, the booking is cancelable in full or in segments. Refer to the
refundPenaltieselements for more information.
isTicketed: If true, a ticket(s) was issued for the booking.
agencyCustomerNumber: The travel agency customer identifier, also known as the customer number or DK number.
creationDetails: User, date, and time regarding the creation of the booking.
contactInfo: Lists all contact info data associated with the booking.
travelers: Lists all traveler(s) associated with the booking.
emails: Lists all email addresses of the traveler.
phones: Lists all phone numbers associated with the traveler.
identityDocuments: Lists all documents associated with the traveler.
loyaltyPrograms: Lists all loyalty programs like the frequent flyer program associated with the traveler.
ancillaries: Lists the details of ancillary services.
travelersGroup: Contains information about the group the travelers belong to.
flights: Lists all flights associated with the booking in chronological order.
journeys: Lists all journeys associated with the booking. For one-way, this is a single element list. For a round-trip, this array contains two journeys. For multi-destination, there are more than two journeys.
fareRules: Lists fare rule information displayed at the time of purchase.
fareOffers: Lists ancillary offers for selected flights identified by itemId flight references.
fares: Lists fare details information based on the active price quotes in the booking.
remarks: Lists all remarks associated with the booking.
hotels: Lists all hotel reservations associated with the booking.
cars: Lists all car rentals associated with the booking.
trains: Lists all train reservations associated with the booking.
cruises: Lists all cruise reservations associated with the booking.
allSegments: Lists all segments in the reservation using a generic model.
flightTickets: Lists all flight tickets associated with the booking.
payments: Contains all total payment amounts across flights, hotels, cars, and trains.
otherServices: Lists Other Service Information (OSI) to/from a specific vendor.
futureTicketingPolicy: Contains a detailed ticket arrangement for a future date.
specialServices: Lists special services for a traveler.
request: Includes a copy of the request sent to the API.
errors: Includes all errors/warnings returned by the API.
This section illustrates the current error handling logic for Get Booking:
|category||String||Indicates error category.|
|description||String||Provides detailed description.|
|type||String||Indicates error type.|
|fieldPath||String||Field path of the error caused by a bad request.|
|fieldName||String||Field name of the error caused by a bad request.|
|fieldValue||String||Field value of the error caused by a bad request.|
In the event an error(s) occurs, Get Booking returns a non-empty
errors list. Each item in the collection contains three fields with possible values:
Note: Refer to the Get Booking - Error List section for additional details on possible errors returned by Get Booking.