Release Notes



Looking for the latest features and enhancements to Sabre APIs? You're in the right place.



Orchestrated Air Booking 3.10.0 on May 21, 2019

Service Action Code: EnhancedAirBookRQ
  • Upgraded response schema to match internal call to TravelItineraryReadRQ version 3.10.0
  • Upgraded request and response schemas to match internal call to OTA_AirPriceLLSRQ version 2.17.0
  • Added /EnhancedAirBookRQ/PostProcessing/ARUNK_RQ to add arrival unknown segments prior pricing
Read more

Corporate Travel Services 1.19.04 on May 7, 2019

Method/Endpoint: *
  • The 19.04 update to the Corporate Travel Services adds validating carrier information to the flight shopping response, adds support for specially formatted phone numbers used with Air Connect, improves error handling, squashes bugs, and delivers several other enhancements.
  • Information about validating carriers has been added to the `GET /catalogs` response. A validating carrier is the airline that issues tickets and receives payment when flights are booked. And in the event of cancellations this is the carrier with which the traveler will have a credit.
  • The validating carrier options are identified for each itinerary when shopping with Search by Price, and the site is configured to use Amadeus webservices, Sabre Intellisell (Super PNR), or Sabre Branded Fares. A new `validatingCarriers` array is present within the `fare` section of the itinerary. Each validating carrier option is specified with a two-character `airlineCode` and the default (or primary) validating carrier choice is indicated when `isDefault` is set to `true`.
  • Formatted phone number. Prior to this release the phone number string (`telephoneNumber`) included in the `POST /bookings` request was used as the phone number in the underlying Air Connect booking process. And if `telephoneNumber` was not included in the `POST /bookings` request then the "Work phone number" from the traveler's profile was used. This process worked okay for "normal" telephone numbers. But for Travelfusion flights this generated an error when the phone number included non-numeric characters, such as "x" preceding the extension part of the phone number.
  • Now the special phone number identified as "Air Connect phone number" in the traveler's profile can be used when making Air Connect bookings (through Travelfusion). This phone number breaks up the phone data into defined pieces and includes the option to include a separate phone extension.
  • Use of this formatted phone number involves the following: * A new `formattedPhoneNumbers` array has been added to the `GET /travelers` response, under `contactInfo`. This array consists of four elements: `countryCode`, `areaCode`, `localNumber`, and `extension`. These elements provide the data from the "Air Connect phone number" in the traveler's profile.
  • * The `GET /carts` response has a new `phoneNumberMustBeFormatted` indicator. This is set to true when a formatted phone number is needed to complete the booking. That is, anytime a Travelfusion flight is part of the itinerary.
  • * The `POST / bookings` request has been extended to add an optional `formattedPhoneNumber` object under `contactInfo`, with elements for `countryCode`, `areaCode`, `localNumber`, and `extension`. This formatted phone data must be included in the `POST /bookings` request anytime `phoneNumberMustBeFormatted` is true in `GET /carts`. (The first three elements are required when this object is included, while `extension` is optional.)
  • It is recommended that when `phoneNumberMustBeFormatted` is true the client application display the `formattedPhoneNumbers` data from `GET /travelers` during the checkout process. The traveler can then make any updates to that data, before the `formattedPhoneNumber` object is submitted as part of the `POST / bookings` request.
  • To provide compatibility with existing webservice clients that have have not yet added support for a formatted phone number, the following hierarchy will be used *temporarily* to determine which phone number is included in the underlying Air Connect booking, when `phoneNumberMustBeFormatted` is true:
  • * `formattedPhoneNumber` object from the `POST /bookings` request.
  • * "Air Connect phone number" from the traveler's profile.
  • * `telephoneNumber` string from the `POST /bookings` request.
  • * "Work phone number" from the traveler's profile.
  • If none of these items hold phone data then `POST /bookings` will return an error with `type` as "MISSING_PHONE_NUMBER".
  • Note that once all clients have added support for a formatted phone number this will be changed in a future release. At that time whenever `phoneNumberMustBeFormatted` is true then only a `formattedPhoneNumber` or the "Air Connect phone number" from the traveler's profile will be used to make the Air Connect booking.
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations: * Attempting to book with an invalid phone number. Previously this situation returned an error under `category` "INVALID_DATA" with `description` "Booking cannot be made. Invalid phone number". Now the error includes `type` = "INVALID_PHONE_NUMBER" and the `description` has been updated to "Booking cannot be made. Phone number is invalid.".
  • * `E_UNABLE_PROCESS_SEG` error when unable to process a flight segment because the segment is not found. Now returns error `type` = "UNABLE_TO_BOOK" under `category` "INTERNAL_SERVER_ERROR" and `description` "Unable to confirm segment - segment not found".
  • This update to the "UNABLE_TO_BOOK" error was incorrectly listed in the [19.03 Release Notes](http://corporatetravel.developer.sabre.com/blog/1903-release-notes). It has now been removed from those notes.
  • Other updates have been made to improve various Corporate Travel Services: * The `isGenderRequired`, `isDateOfBirthRequired`, and `isRedressNumberRequired` indicators in `GET /carts` have been updated to provide more accurate information. Previously, these indicators were set without first checking to see if Secure Flight Passenger Data was enabled in Site Administration (under Setup > Pages > Checkout > Traveler Information). Now the status of that setting is reviewed when setting these indicators.
  • * The marketing airline and operating airline information has been standardized within the itinerary portions of the `GET /catalogs`, `GET /carts`, and `GET /bookings` responses. Marketing airline information is always included in the `marketingAirlineCode` and `marketingAirlineName` elements for each response. But now the `operatingAirlineCode` (for non-codeshare flights) or the `operatingAirlineName` (for codeshare flights) is only included in the responses when the corresponding Site Administration setting is configured to "Display codeshare carrier information on the Flight/Equipment column on Flight Availability page?" (under Air > AirPages). If that toggle is set to not display then neither `operatingAirlineCode` or `operatingAirlineName` is included in the responses.
  • * `vouchers` has been removed from the `GET /travelers` response and `acceptableVouchers` has been added to the `GET /carts` response. This voucher data describes active Residual Travel Fund (RTF) vouchers for Southwest Airlines, issued when certain types of flights are cancelled. In an upcoming release these vouchers can be used when booking a Southwest flight through Air Connect as an alternative/additional form of payment.
  • * As foretold in the [19.03 Release Notes](http://corporatetravel.developer.sabre.com/blog/1903-release-notes), `totalTripCost` has changed its element name to `totalBookingCost` in the `GET /bookings` response.
  • * The shopping window for Air Connect flights now honors the `hoursTolerance` setting included in the `POST /catalogs` request. Before this release the `hoursTolerance` setting only affected GDS flight shopping, and Air Connect used the time window setting from Site Administration (under Setup > Air Connect).
  • Note: When shopping on TravelFusion it is possible to shop for a time window that crosses midnight, depending on the `hoursTolerance` and time sent in the `POST /catalogs` request.
Read more