Release Notes



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



Corporate Travel Services 1.17.11 on October 26, 2017

Method/Endpoint: *
  • The 17.11 update adds a new service to check the status of Corporate Travel APIs, provides basic trip information when retrieving a booking, fixes a pricing issue in low fare rebook situations, allows confirmation emails to be disabled, and includes other enhancements and updates. No API version numbers have changed since all of the changes are backwards compatible, and all new elements added to schemas are opti onal.
  • `GET /deployment` This new service provides an easy way to check the status of and obtain information about the Corporate Travel APIs. The service lists the environment, version, build-date, and endpoints of all active APIs. See [API Reference](/reference#getdeploymentinfo) for more information.
  • `GET /catalogs' and `GET /farerules' To improve shopping responsiveness a change has been made to the way fare rules are indexed and retrieved. This change means that the format of the `fareRulesId` in the response from `GET /catalogs` has changed, along with the format of the `id` used when retrieving fare rules with `GET /farerules`. See [Details for FareRules](#section-details-for-farerules).
  • `GET /bookings` Itinerary and other trip information from a booking is now returned in the response. See [Details for Booking Response](#section-details-for-booking-response).
  • `POST /catalogs' Several changes have been made to provide better information when an issue is found with `departDate` or `returnDate`. Now a 422 error is returned along with a verbose error `description` if either of these dates are in the past, if either date is too far in the future, or if `departDate` is not before `returnDate`. Previously a generic 400 or 500 error was returned in these situations.
  • `POST /catalogs` If `classOfService` and/or `fareType` is not included in the request the configured default value(s) from Site Administration are used for shopping.
  • `POST /bookings` If required information is missing (or incorrectly formatted) in the `supplementaryData` section of the request request a meaningful error is now returned.
  • `POST /bookings` The issue has been resolved which prevented Business or First class bookings on Apollo when using a negotiated fare code.
  • `POST /bookings` Special characters are now allowed in the Agency address as configured in Site Administration. (There were no changes to the services. The previous issue with multi-byte characters was due to mis-configuration of a service startup setting.)
  • `POST /bookings` A new setting the GetThere Site Administration tool to control confirmation e-mails is now supported by `POST /bookings`. If confirmation e-mails should not be sent to traveler as part of the booking process, this toggle can be disabled in Site Administration under User > Automatic E-mails > Booking Confirmation tab.
  • Details for Booking Response. The `GET /bookings` response has been enhanced to return additional information about the booking, beyond just the main confirmation number (PNR). Information is being added to the response incrementally, with additional fields to be added in an upcoming release. Please note that [the API Reference](/reference#createbooking) is not correct regarding this update as it includes several data fields that are not yet being sent, and several that will be dropped from the model (because they are not available after a booking is made). The API Reference will be updated soon to provide more accurate information.
  • Details for FareRules. We found shopping requests with `GET /catalogs` were taking too long due to the way the `fareRulesId` was generated and stored. Each individual itinerary in the shopping response created a separate entry in an internal cache – which entailed a significant amount of overhead. To reduce shopping time the `fareRulesId` has changed format so it now includes the key information used to access fare rules embedded within its structure. This allows the `id` to be used with `GET /farerules` and eliminates the need to create these separate entries in the internal cache.
  • Although the format of the `fareRulesId` has changed, no changes should be required in the client application as long as the same `fareRulesId` from `GET /catalogs` is used as the `id` with `GET /farerules` .
  • Example of old `fareRulesId`: "d82c8a9f-aa02-46ae-835f-a737e62dd939"
Read more

Corporate Travel Services 1.17.10 on October 5, 2017

Method/Endpoint: *
  • The 17.10 update adds 24-hour shopping to the Corporate Travel APIs, along with other enhancements and updates.
  • No API version numbers have changed since all of the changes are backwards compatible, and all new elements added to schemas are optional. Swagger documentation has also been updated.
  • `POST /catalogs` 24-hour shopping is now available for sites configured with a Sabre or Travelport GDS (Apollo or Galileo) using a new `hoursTolerance` element. See [Details for 24-hour Shopping](#section-details-for-24-hour-shopping).
  • `GET /catalogs` A new `fareBasis` element identifying the flight’s fare basis code has been added to the `flights` portion of the response within `journeys`, under `itineraries`. See [Details for Fare Basis](#section-details-for-fare-basis).
  • `GET /travelers` The user’s email address from their profile is now correctly *returned *in the `contactInfo` portion of the response within `emailAddresses`.
  • `GET /travelers` If a regex string is configured for a Custom Field Edit (CFE) in `supplementaryDataGroups` that regex takes precedence over any settings for type, min, or max.
  • `POST /catalogs` Correct error information (403, SUPPLIER_ERROR) is now returned when a request times-out or has too many retries. Previously this situation was incorrectly flagged as missing information for TSA Secure Flight.
  • `POST /catalogs` Validation has been added to reject a request with dates in the past (`departDate`, `returnDate`, or `date`). Requests with such dates now return an error (400, INVALID_DATA, date).
  • `POST /bookings` The `namePrefix` element included in the request is now correctly populated during the booking process. See [Details for Booking Process](#section-details-for-booking-process).
  • `POST /bookings` The model for `POST /bookings` on Swagger has been updated to correctly identify required fields. See [Details for Booking Information](#section-details-for-**booking**-information).
  • Details for 24-hour Shopping. 24-hour shopping is invoked by using the new optional `hoursTolerance` parameter in the `POST /catalogs` request. This is an integer (0-12) which overrides the search settings in Site Administration under Air > Air Configuration > Air Configuration > Fare Options > Fare Led Settings. This value specifies the hours to search before and after the `departTime` and `returnTime` defined elsewhere in the request (or before and after `time` on a `oneWay` request).
  • The actions to specify 24-hour shopping vary slightly depending on which GDS is used by the site:
  • *Sabre* GDS.
  • * The site needs to be configured to use SuperPNR with Intellisell (for search by price). This is a Super User setting in Site Administration (under Air), so you need to work with the implementation services team to update existing sites. (*Update 13 Nov 17*: Branded Fares no longer needs to be enabled to use Intellisell.)
  • * A value of 12 must be sent in `hoursTolerance`. (A value of 10 or 11 will also yield 24-hour shopping, but this is not recommended.)
  • * The `departTime` and `returnTime` values (or `time` value) in the shopping request are ignored when `hoursTolerance` is present with a value of 12 (also with 10 or 11).
  • * If any other value is used for `hoursTolerance` (1 - 9) that number is used to calculate a search window by adding and subtracting this value from the `departTime` or `returnTime` (or `time`), up to midnight.
  • * Search windows are confined to a single date and will never extend beyond midnight. So if 8 is sent in `hoursTolerance` along with a `departTime` of 20:00 (8:00 pm), the search window will be 12:00 noon to midnight.
  • *Travelport* GDS (Apollo or Galileo).
  • * No special Site Administration setup is needed.
  • * A value of 12 must be sent in `hoursTolerance`.
  • * The `departTime` and `returnTime` values (or `time` value) must be set to noon (12:00).
  • * The `hoursTolerance` value is used to calculate a search window by adding and subtracting this value from the `departTime` or `returnTime` (or `time`), up to midnight.
  • * Search windows are confined to a single date and will never extend beyond midnight. So if 10 is sent in `hoursTolerance` along with a `departTime` of 06:00 (6:00 am), the search window will be midnight to 4:00 pm.
  • Details for Fare Basis. The fare basis code has been added to each flight in the `GET /catalogs` response. It may be helpful to combine the fare basis code with response data from the `GET /fareRules` service when retrieving fare rules from Apollo or Galileo. Fare rules from these Travelport GDS’s do not include the “header” information that repeats the fare basis code, as is shown with fare rules retrieved from Sabre or Amadeus.
  • Details for Booking Process. Proper handling of the `namePrefix` in `POST /bookings` means it is no longer necessary to use the workaround of allowing name changes during booking. The setting in Site Administration under Setup > Pages > Checkout on the Traveler Information tab can now be set to either enable or disable the option to “Permit travelers to edit the Traveler Information name fields (first name, middle name, last name)”.
  • Swagger has been updated to identify required elements in the `POST /bookings` request:
  • * `travelerId` * `components` * `bookableFlightItinerary` * `itineraryId` * `type` and `code` (when the optional `justifications` is present) * `paymentCard` * `paymentCardId` * `travelers` * `travelerId` * `personalIdentifiableInformation` * `firstName` * `lastName`
Read more