Skip to main content

Corporate Travel Services

v1
Corporate
Reservation
REST API
Travel Agency
Try Now
release_note
  • Corrected an issue with missing confirmation number in `GET /bookings` response when flight is a code share. The confirmation number is now included.
  • Updated the support for Overridable Payment Cards. Two small issues specific to the APIs were corrected:
  • > It is now possible to book an itinerary when the 'POST /carts/bookings' request contains a `billingAddress` object. That billingAddress will override the billing address of an Overridable Card (the "dummy" site card), but the billing address from the Override Card will actually override either of those addresses.
  • > The billing card validation around "billing address" has been relaxed. It is now possible to book Air Connect flights without a billing address in the 'POST /carts/bookings' request or in the Overridable Card, since the address can come from the Override Card. However, if the resulting billing address is incomplete an error will be returned, depending on which Air Connect vendor is being used and the details of which address element is missing:
  • >> Agentware. When all address fields are empty the error response will be `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description` of "Booking cannot be made. Payment card declined. Unable to make the booking. Booking failure caused by:Agentware.Booking.Error.CreditCard.Country.Missing". Or if all the address fields are empty except the country the error will be `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description of "Booking cannot be made. Payment card declined. Unable to make the booking. Booking failure caused by: Booking.CreditCard.AddressMissing".
  • >> Travelfusion. If the street address is missing the error is `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description` of "Booking cannot be made. Payment card declined. Invalid street name". A missing city name results in `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description` with "Booking cannot be made. Payment card declined. Invalid city name". And a missing country will return `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and the `description` of "Booking cannot be made. Payment card declined. Invalid country code".

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.20.02
Target Audience
TN
Environment
Production

What's New

  • Corrected an issue with missing confirmation number in `GET /bookings` response when flight is a code share. The confirmation number is now included.
  • Updated the support for Overridable Payment Cards. Two small issues specific to the APIs were corrected:
  • > It is now possible to book an itinerary when the 'POST /carts/bookings' request contains a `billingAddress` object. That billingAddress will override the billing address of an Overridable Card (the "dummy" site card), but the billing address from the Override Card will actually override either of those addresses.
  • > The billing card validation around "billing address" has been relaxed. It is now possible to book Air Connect flights without a billing address in the 'POST /carts/bookings' request or in the Overridable Card, since the address can come from the Override Card. However, if the resulting billing address is incomplete an error will be returned, depending on which Air Connect vendor is being used and the details of which address element is missing:
  • >> Agentware. When all address fields are empty the error response will be `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description` of "Booking cannot be made. Payment card declined. Unable to make the booking. Booking failure caused by:Agentware.Booking.Error.CreditCard.Country.Missing". Or if all the address fields are empty except the country the error will be `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description of "Booking cannot be made. Payment card declined. Unable to make the booking. Booking failure caused by: Booking.CreditCard.AddressMissing".
  • >> Travelfusion. If the street address is missing the error is `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description` of "Booking cannot be made. Payment card declined. Invalid street name". A missing city name results in `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and a `description` with "Booking cannot be made. Payment card declined. Invalid city name". And a missing country will return `category` = INVALID_DATA, `type` = INVALID_BILLING_ADDRESS, and the `description` of "Booking cannot be made. Payment card declined. Invalid country code".

Relase note ID: 14214


  • The 1.20.01 update to the Corporate Travel Services is focused on Air Connect and Travelfusion. Error responses have been added or improved with more information, and flight options in the Catalog are now limited to align the content from all shopping sources.
  • Air Connect Content. The `GET /catalogs` response no longer returns flights from Travelfusion with a departure date that is different from the requested shopping date. This matches the behavior of Agentware shopping and GDS shopping when using Search by Price.
  • Improved Error Handling. Error messages associated with Air Connect and Travelfusion have been added for some situations or improved to add elements that were previously missing:
  • > Travelfusion encountered an error and says the selected fare is no longer available. A new response has been created to return error `type` = "FLIGHT_NOT_AVAILABLE" under `category` "EXPIRED_DATA" with `description` of "Flight is no longer available".
  • > Travelfusion says the phone number is invalid. The `type` has been added. These now return error `type` = " INVALID_PHONE_NUMBER" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Phone number is invalid.".
  • > The passenger name sent to Travelfusion contains invalid characters. The `type` has been added. These situations now return error `type` = "INVALID_NAME" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Invalid name".
  • > Travelfusion responds that the billing address is incorrect. A new response has been created to return error `type` = "INVALID_BILLING_ADDRESS" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Payment card declined. Invalid address". This message has several variations depending on the specific message returned from the airline/bank during payment processing. Each form of the error includes additional text in the `description` to identify what is wrong with the address. For example, "Invalid address (The province of the billing address needs to be supplied)".

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.20.01
Target Audience
TN
Environment
Production

What's New

  • The 1.20.01 update to the Corporate Travel Services is focused on Air Connect and Travelfusion. Error responses have been added or improved with more information, and flight options in the Catalog are now limited to align the content from all shopping sources.
  • Air Connect Content. The `GET /catalogs` response no longer returns flights from Travelfusion with a departure date that is different from the requested shopping date. This matches the behavior of Agentware shopping and GDS shopping when using Search by Price.
  • Improved Error Handling. Error messages associated with Air Connect and Travelfusion have been added for some situations or improved to add elements that were previously missing:
  • > Travelfusion encountered an error and says the selected fare is no longer available. A new response has been created to return error `type` = "FLIGHT_NOT_AVAILABLE" under `category` "EXPIRED_DATA" with `description` of "Flight is no longer available".
  • > Travelfusion says the phone number is invalid. The `type` has been added. These now return error `type` = " INVALID_PHONE_NUMBER" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Phone number is invalid.".
  • > The passenger name sent to Travelfusion contains invalid characters. The `type` has been added. These situations now return error `type` = "INVALID_NAME" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Invalid name".
  • > Travelfusion responds that the billing address is incorrect. A new response has been created to return error `type` = "INVALID_BILLING_ADDRESS" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Payment card declined. Invalid address". This message has several variations depending on the specific message returned from the airline/bank during payment processing. Each form of the error includes additional text in the `description` to identify what is wrong with the address. For example, "Invalid address (The province of the billing address needs to be supplied)".

Relase note ID: 13886


  • The 1.19.09 update to the Corporate Travel Services adds hotel payment information to the `GET /travelers` response, addresses an issue with the new Booking Connectivity Service (BCS), and includes additional error handling when using Strong Customer Authentication (SCA).
  • Traveler Credit Card Information. The `GET /travelers` response now identifies the preferred payment card for hotels (under `preferences`), and includes hotel card summary information (under `paymentCards`). This information can be used to distinguish between user-assigned profile card preferences vs. default preference assignments, in situations where the profile synchronization process creates default assignments.
  • Improved Error Handling. New error messages have been added for the following error situations associated with Strong Customer Authentication (SCA) - remember that more information about SCA can be found in the Release Notes for 1.19.07 and 1.19.08:
  • > The `paymentAuthenticationReturnUrl` is missing in the `POST /carts/{id}/booking` request when this element is required by the `mayRequirePaymentAuthentication` indicator in the `GET /carts` response. The new error is `type` = "MISSING_PAYMENT_AUTHENTICATION_RETURN_URL" under `category` "MISSING_DATA" with a `description` of "Booking cannot be made. In order to make a booking, payment authentication return url is required.".
  • > When payment authentication fails because an error is returned by TravelFusion, or when an attempt is made to resume a booking with `PATCH /bookings` for a booking that was not pending authentication or has failed authentication. These situations return error `type` = "PAYMENT_AUTHENTICATION_FAILED" under `category` "INVALID_DATA" with a `description` of "Booking cannot be made. Payment hasn't been successfully authenticated.".

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.09
Target Audience
TN
Environment
Production

What's New

  • The 1.19.09 update to the Corporate Travel Services adds hotel payment information to the `GET /travelers` response, addresses an issue with the new Booking Connectivity Service (BCS), and includes additional error handling when using Strong Customer Authentication (SCA).
  • Traveler Credit Card Information. The `GET /travelers` response now identifies the preferred payment card for hotels (under `preferences`), and includes hotel card summary information (under `paymentCards`). This information can be used to distinguish between user-assigned profile card preferences vs. default preference assignments, in situations where the profile synchronization process creates default assignments.
  • Improved Error Handling. New error messages have been added for the following error situations associated with Strong Customer Authentication (SCA) - remember that more information about SCA can be found in the Release Notes for 1.19.07 and 1.19.08:
  • > The `paymentAuthenticationReturnUrl` is missing in the `POST /carts/{id}/booking` request when this element is required by the `mayRequirePaymentAuthentication` indicator in the `GET /carts` response. The new error is `type` = "MISSING_PAYMENT_AUTHENTICATION_RETURN_URL" under `category` "MISSING_DATA" with a `description` of "Booking cannot be made. In order to make a booking, payment authentication return url is required.".
  • > When payment authentication fails because an error is returned by TravelFusion, or when an attempt is made to resume a booking with `PATCH /bookings` for a booking that was not pending authentication or has failed authentication. These situations return error `type` = "PAYMENT_AUTHENTICATION_FAILED" under `category` "INVALID_DATA" with a `description` of "Booking cannot be made. Payment hasn't been successfully authenticated.".

Resolved Issues

In the Request/Response

N/A

General Improvements. An issue with the new Booking Connectivity Service (BCS) has been corrected. This problem was around handling the ticketing time limit for bookings made from CTS, specifically with the `POST /carts/{id}/bookings` endpoint. Now bookings made with BCS are handled properly, clearing the way for clients to switch ticketing to BCS.

Relase note ID: 13361


  • The 1.19.08 update to the Corporate Travel Services corrects some issues when using Bargain Finder Max (BFM) - an upgrade to the Sabre flight shopping service. It also eliminates some confusion around baggage information in the Catalog and Cart content; and it adds support for the Strong Customer Authentication (SCA) initiative in Europe.
  • Strong Customer Authentication (SCA). SCA is a requirement of the EU Revised Directive on Payment Services (PSD2) affecting payment service providers within the European Economic Area. The SCA requirement is expected to come into force starting 14 September 2019.
  • The two new fields added to support SCA in the 1.19.07 release are now functional: the boolean indicator `mayRequirePaymentAuthentication` in the `GET /carts` response and the `paymentAuthenticationReturnUrl` element in the `POST /carts/{id}/bookings` request. (See the 1.19.07 Release Notes for more details.)
  • After the traveler returns from authentication a `PATCH /bookings` request needs to be submitted with `finalizeBooking` = "true". This tells the system to resume polling to check for a response to the original booking request; testing to see if the booking is complete. The service will respond by returning `status` = "204".
  • Also, the following error messages have been added to support SCA:
  • > Traveler tries to resume a booking without completing payment authentication. The error is `type` = "PAYMENT_AUTHENTICATION_FAILED" under `category` "INVALID_DATA" with the `description` "Payment hasn't been successfully authenticated."
  • > If `paymentAuthenticationUrl` is not included in the `POST /carts/{id}/bookings` request when required (i.e., when `mayRequirePaymentAuthentication` is `true` in the `GET /carts` response). This error is `type` = "MISSING_PAYMENT_AUTHENTICATION_RETURN_URL" under `category` "MISSING_DATA" with a `description` of "In order to make a booking, payment authentication return url is required."

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.08
Target Audience
TN
Environment
Production

What's New

  • The 1.19.08 update to the Corporate Travel Services corrects some issues when using Bargain Finder Max (BFM) - an upgrade to the Sabre flight shopping service. It also eliminates some confusion around baggage information in the Catalog and Cart content; and it adds support for the Strong Customer Authentication (SCA) initiative in Europe.
  • Strong Customer Authentication (SCA). SCA is a requirement of the EU Revised Directive on Payment Services (PSD2) affecting payment service providers within the European Economic Area. The SCA requirement is expected to come into force starting 14 September 2019.
  • The two new fields added to support SCA in the 1.19.07 release are now functional: the boolean indicator `mayRequirePaymentAuthentication` in the `GET /carts` response and the `paymentAuthenticationReturnUrl` element in the `POST /carts/{id}/bookings` request. (See the 1.19.07 Release Notes for more details.)
  • After the traveler returns from authentication a `PATCH /bookings` request needs to be submitted with `finalizeBooking` = "true". This tells the system to resume polling to check for a response to the original booking request; testing to see if the booking is complete. The service will respond by returning `status` = "204".
  • Also, the following error messages have been added to support SCA:
  • > Traveler tries to resume a booking without completing payment authentication. The error is `type` = "PAYMENT_AUTHENTICATION_FAILED" under `category` "INVALID_DATA" with the `description` "Payment hasn't been successfully authenticated."
  • > If `paymentAuthenticationUrl` is not included in the `POST /carts/{id}/bookings` request when required (i.e., when `mayRequirePaymentAuthentication` is `true` in the `GET /carts` response). This error is `type` = "MISSING_PAYMENT_AUTHENTICATION_RETURN_URL" under `category` "MISSING_DATA" with a `description` of "In order to make a booking, payment authentication return url is required."

Resolved Issues

In the Response

N/A

Sabre Shopping. Bargain Finder Max (BFM) is an enhanced version of Sabre's Intellisell flight shopping webservice. Two issues have been corrected that prevented CTS from upgrading to BFM from an older version of Intellsell. This means the `POST /catalogs` service will switch to BFM with this release. The issues were:

In the Response

N/A

* A problem with 24-hour shopping has been fixed. Now when a `POST /catalogs` request includes `hoursTolerance` = "12" flights will be returned from the entire day. And when `hoursTolerance` is specified as any other value (an integer from 0-11), flights will be returned using a time window based on the `departTime` (or `time`) included in the request, plus and minus the `hoursTolerance` value. (Remember that a time window can be constructed which crosses midnight, but flights from any other day will not be included in the response.)

In the Response

N/A

* The mapping for `cabinTypeName` has been updated. Now flights in the `GET /catalogs` response specify the correct class of service.

In the Response

N/A

Bag Information. A problem with baggage information has been addressed for flights from the Sabre GDS in the `GET /catalogs` response (and in the `alternativeFlightItineraries` section of the `GET /carts` response). The `firstPiece` and `lastPiece` elements under `freeTextPolicy` have been removed to avoid confusion. These parameters are only used with paid bags (not yet supported), and have no meaning for free bags. Remember that baggage information is only available from Sabre when shopping is done using Bargain Finder Max (BFM).

In the Response

N/A

General Improvements. A problem has been fixed which resulted in the wrong number of journeys being shown in a `GET / catalogs` response when the `POST /catalogs` request was for `RoundTrip` and `shopByPrice`, and the site was using a Travelport GDS.

Relase note ID: 13360


  • The 1.19.07 update to the Corporate Travel Services address a couple of issues, updates error handling, and prepares the APIs for upcoming changes related to Strong Customer Authentication (SCA).
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations:
  • > Traveler age is too young on Agentware. The new error is `type` = "TRAVELER_TOO_YOUNG" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Traveler must be 12 years of age or older.".
  • > Connection time between flights is too short. This is error `type` = "INSUFFICIENT_CONNECTING_TIME" under `category` "INVALID_DATA" with `description` of "Insufficient connecting time between journeys".
  • Strong Customer Authentication (SCA). SCA is a requirement of the EU Revised Directive on Payment Services (PSD2) affecting payment service providers within the European Economic Area. The SCA requirement is planned to come into force starting 14 September 2019. In preparation for SCA new fields have been added to the CTS APIs. These new items are present in the 1.19.07 release, but are not active (functional) and will not be required until 1.19.08:
  • > A boolean indicator `mayRequirePaymentAuthentication` has been added to the `GET /carts` response. When this is true it means the Cart includes a Travelfusion itinerary and SCA may be in effect.
  • > The element `paymentAuthenticationReturnUrl` has been added to the `POST /carts/{id}/bookings` request. This is the URL to which the traveler will be redirected after they have completed the authentication process. This new element is at the same level as `components` and `travelers` in the request. Starting in 1.19.08 a value needs to be provided for this element whenever `mayRequirePaymentAuthentication=true` in the Cart.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.07
Target Audience
TN
Environment
Production

What's New

  • The 1.19.07 update to the Corporate Travel Services address a couple of issues, updates error handling, and prepares the APIs for upcoming changes related to Strong Customer Authentication (SCA).
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations:
  • > Traveler age is too young on Agentware. The new error is `type` = "TRAVELER_TOO_YOUNG" under `category` "INVALID_DATA" with `description` of "Booking cannot be made. Traveler must be 12 years of age or older.".
  • > Connection time between flights is too short. This is error `type` = "INSUFFICIENT_CONNECTING_TIME" under `category` "INVALID_DATA" with `description` of "Insufficient connecting time between journeys".
  • Strong Customer Authentication (SCA). SCA is a requirement of the EU Revised Directive on Payment Services (PSD2) affecting payment service providers within the European Economic Area. The SCA requirement is planned to come into force starting 14 September 2019. In preparation for SCA new fields have been added to the CTS APIs. These new items are present in the 1.19.07 release, but are not active (functional) and will not be required until 1.19.08:
  • > A boolean indicator `mayRequirePaymentAuthentication` has been added to the `GET /carts` response. When this is true it means the Cart includes a Travelfusion itinerary and SCA may be in effect.
  • > The element `paymentAuthenticationReturnUrl` has been added to the `POST /carts/{id}/bookings` request. This is the URL to which the traveler will be redirected after they have completed the authentication process. This new element is at the same level as `components` and `travelers` in the request. Starting in 1.19.08 a value needs to be provided for this element whenever `mayRequirePaymentAuthentication=true` in the Cart.

Resolved Issues

In the Response

N/A

Other updates have been made to improve various CTS endpoints:

In the Response

N/A

* Fixed an issue with the currency of `quotedPrice` for seats under `AirExtras` in the `GET /seatmaps` and `GET /carts` responses.

In the Response

N/A

* The voucher amount debited has been corrected in the `GET /bookings` response, in the `appliedVouchers` section. Previously there was an issue with the implied decimal location, so a value of `20400` was shown as `204`, for example.

Relase note ID: 13362


  • The 19.06 update to the Corporate Travel Services improves the way Travel Policy is applied during 24-hour shopping, significantly improves the response time of `GET /travelers` requests, adds a small enhancement for branded fares, and updates error handling for a specific scenario.
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations: * Departure time is too close to current time (when using Search by Time). Following the 19.05 release this situation was returning `500 INTERNAL SERVER ERROR` . Now the error is as it was before 19.05, with `type` = "DEPARTURE_TIME_TOO_CLOSE" under `category` "POLICY_VIOLATION" with `description` of "Departure time is too close to the current time based on the policy setup for the site".
  • Other updates have been made to improve various Corporate Travel Services: * In the Search by Time path `fareBrandId` has been added to the `GET /catalogs` response (on flights with brands).
  • * 24-hour shopping no longer requires that the `time` in the `POST /catalogs` request be set to "12:00", as was previously required (depending on the GDS). Now a 24-hour search is performed simply by including `hoursTolerance` as "12" in the request. This allows the `time` from the `POST /catalogs` request to be used in Travel Policy to calculate *Lowest Logical Fare* and apply that to flights. Specifically, when Travel Policy includes an *Ideal Air Itinerary* rule, that `time` is used to determine the *Ideal Air Itinerary* and the corresponding *Lowest Logical Fare*. That *Lowest Logical Fare* is then used to evaluate the price of each flight in the `GET /catalogs` response and determine which flights are "out of policy".
  • Note: For one-way shopping `time` is the element used in Travel Policy evaluation. When doing round-trip shopping the element name is `departTime`.
  • * The performance of `GET /travelers` has been greatly improved. A request should now return in about 10%-30% of the time previously seen.
  • The *first* `GET /travelers` request sent for a given main site (supersite) will still take extra time. But all subsequent requests - for any traveler on any subsite under that main site - will be returned much more quickly. The improved performance will continue until the cached information expires, 1 hour later. However, any `GET /travelers` request or `POST /catalogs` request send during that time will reset the cache timer, restarting the 1 hour countdown.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.06
Target Audience
TN
Environment
Production

What's New

  • The 19.06 update to the Corporate Travel Services improves the way Travel Policy is applied during 24-hour shopping, significantly improves the response time of `GET /travelers` requests, adds a small enhancement for branded fares, and updates error handling for a specific scenario.
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations: * Departure time is too close to current time (when using Search by Time). Following the 19.05 release this situation was returning `500 INTERNAL SERVER ERROR` . Now the error is as it was before 19.05, with `type` = "DEPARTURE_TIME_TOO_CLOSE" under `category` "POLICY_VIOLATION" with `description` of "Departure time is too close to the current time based on the policy setup for the site".
  • Other updates have been made to improve various Corporate Travel Services: * In the Search by Time path `fareBrandId` has been added to the `GET /catalogs` response (on flights with brands).
  • * 24-hour shopping no longer requires that the `time` in the `POST /catalogs` request be set to "12:00", as was previously required (depending on the GDS). Now a 24-hour search is performed simply by including `hoursTolerance` as "12" in the request. This allows the `time` from the `POST /catalogs` request to be used in Travel Policy to calculate *Lowest Logical Fare* and apply that to flights. Specifically, when Travel Policy includes an *Ideal Air Itinerary* rule, that `time` is used to determine the *Ideal Air Itinerary* and the corresponding *Lowest Logical Fare*. That *Lowest Logical Fare* is then used to evaluate the price of each flight in the `GET /catalogs` response and determine which flights are "out of policy".
  • Note: For one-way shopping `time` is the element used in Travel Policy evaluation. When doing round-trip shopping the element name is `departTime`.
  • * The performance of `GET /travelers` has been greatly improved. A request should now return in about 10%-30% of the time previously seen.
  • The *first* `GET /travelers` request sent for a given main site (supersite) will still take extra time. But all subsequent requests - for any traveler on any subsite under that main site - will be returned much more quickly. The improved performance will continue until the cached information expires, 1 hour later. However, any `GET /travelers` request or `POST /catalogs` request send during that time will reset the cache timer, restarting the 1 hour countdown.

Relase note ID: 13944


  • The 19.05 update to the Corporate Travel Services adds baggage information to flight shopping, allows Southwest RTF vouchers to be used when making a new booking, and adds support for a new type of overridable payment card that can be used with Air Connect flights. In addition this release improves error handling, adds other small enhancements, cleans up the API schemas, and squashes a few bugs.
  • Baggage allowance information has been added to the `GET /catalogs` response when using search by price, and to the `GET /**carts**` response when using search by time (but only for `alternativeFlightItineraries`). A new `flightBaggagePolicies` array describes the allowed "free bags" for an itinerary - as indicated by `feeApplies` set to "false". Three types of baggage information can be included, depending on the GDS, the market, and the airline: * Quantity. The `numberOfPieces` which are included for the fare. Example:
  • * Weight (and quantity). The `numberOfPieces` which are included for the fare, along with the `maximumWeight` (and the unit of weight).
  • * Descriptive text. Free text provided by the airline that describes the baggage restrictions for the fare. Note that `firstPiece` and `lastPiece`are not currently set correctly in this view. This will be updated in a future release.
  • Note: Baggage allowance information is only available from the latest webservice shopping options, not through older webservices or when using classic "green screen" shopping. That means only when using Amadeus' Travelboard, Sabre's Bargain Finder Max, or TravelPorts universal API.
  • Residual Travel Funds and Southwest Airlines
  • When a booking on Southwest Airlines (WN) is cancelled it can generate a Residual Travel Fund (RTF). These RTFs are a type of travel voucher managed by Southwest Airlines, and can be applied when making a future booking on the airline.
  • When a Southwest RTF is created it is added to a list of RTFs for that traveler, which is maintained in our system. When a traveler shops for their next trip on Southwest, up to five of that traveler’s RTFs (the oldest) are sent to Southwest Airlines via the Air Connect aggregator during `GET /carts` re-pricing, to confirm viability and remaining value. The information returned from Southwest is used to populate the `acceptableVouchers` section of the `GET /carts` response. This array includes a `voucherCode` which identifies each RTF, its `expirationDate`, the original value of the RTF (`initialValue`) and the available `amount` that can be applied to another booking (`currentBalance`).
  • The traveler should be presented with this RTF information as one of the possible forms of payment for the booking in progress. (Note that if a RTF is returned with a value of "0" that RTF cannot be used for a booking and should not be presented to the traveler.) The traveler can elect to use none, some, or all of the available RTFs in the booking process. To apply the RTFs towards the booking the `POST /carts/{id}/bookings` request needs to include the `paymentVouchers` object along with the selected `voucherCode`(s).
  • The `voucherCode`(s) in the request are sent to Southwest Airline (through the Air Connect aggregator). Ultimately Southwest decides which vouchers are used and how much of its value is applied to the new booking. (But normally the RTFs are used oldest to newest.) The `GET/bookings` response will identify the RTFs used for any booking under `appliedVouchers`, and includes the `amountDebited` for each RTF.
  • Helpful hints: * RTFs are only created when a “Wanna Get Away” booking is cancelled (not voided). This is a non-refundable brand from Southwest Airlines. Other brands - such as "Business Select" or "Anytime" - will generate a refund to the payment card when cancelled.
  • * The only RTFs available through the APIs are for bookings cancelled using the `PATCH /bookings` API (or the GetThere online booking tool). RTFs generated in any other way are not accessible. RTFs generated from a cancelled booking can be viewed under `issuedVouchers` in the `GET/bookings` response.
  • * A RTF can only be applied to a booking on Southwest Airlines when using Air Connect. RTFs cannot be used for a Southwest booking through a GDS. Additionally, passive segments must be enabled for Air Connect in order to make a booking with a RTF.
  • * A payment card must be included in the `POST /carts/{id}/bookings` request. A request with only RFT `voucherCode`(s) will be rejected.
  • * While up to five RTFs are sent to the Air Connect aggregator, at this time only the oldest two RTFs are sent on to Southwest. This a a limitation of the Southwest API. This API is in the process of being updated to support an additional number of RTFs. Any change to increase the number of RTFs between the aggregator and Southwest will be automatic from the viewpoint of the Corporate Travel Service APIs. But care should be taken to make sure the client's Checkout page can support up to five RTFs, as the number increases.
  • Overridable Site Card: Support has been added to the Corporate Travel Service APIs for a new "Payment Override" feature based on a new type of corporate Site Card, called an "Overridable Site Card". The "Overridable Site Card" is a placeholder for an actual payment card that will be chosen from a list of many possible payment cards, based on some defined criteria in the traveler’s profile. A form of this capability has been available for some time, but that could only be used for bookings in a GDS since the older feature relies on strings written to the PNR. This new option can be used for non-GDS bookings, such as those for Air Connect.
  • Details regarding the new payment option are detailed in documentation available from GetThere University. Use of this feature is transparent to the APIs with the exception of error handling. The following have been added to the `POST /carts/{id}/bookings` response to handle two possible situations that can arise when using this feature:
  • * The Card Type of the "Overridable Site Card" does not match the Card Type for the actual override payment card selected based on "Unique Name". In this situation an error is returned with `type` = "PAYMENT_OVERRIDE_CARD_TYPE_MISMATCH" under `category` "BAD_CONFIGURATION", with `description` "Payment override card type mismatch".
  • * A match cannot be made between the lookup value of the "Overridable Site Card" (the Profile CFE or Profile Field value) and any "Unique Name" in the table of Payment Override Charge Cards. If this happens an error of `type` = "PAYMENT_OVERRIDE_CARD_NOT_FOUND" is returned under `category` "BAD_CONFIGURATION", with `description` "Payment override card not found".
  • Note: The new "Payment Override" option can only be used in situations where a CVV is not required to complete the booking.
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations: * TravelFusion error with "Results no longer available" during `GET /carts` repricing. This situation now returns error `type` = "FLIGHT_NOT_AVAILABLE" under `category` "EXPIRED_DATA", with `description` "Flight is no longer available".
  • * TravelFusion error with "Your card issuer has rejected your payment" during `POST /carts/{id}/bookings`. Now returns error `type` = "PAYMENT_DECLINED" under `category` "INVALID_DATA", with `description` "Booking cannot be made. Payment card declined. Your card issuer has rejected your payment. (Transaction not permitted to cardholder.)".
  • Other Enhancements and General Improvements. Other updates have been made to improve various Corporate Travel Services: * An issue has been fixed where the `numberOfStops` was not correct in the `GET /catalogs` response on flights from Amadeus that have a layover, but no change of flight number.
  • * A `totalFees` items has been added to the `GET /bookings` response in the `fare` section. This summarizes items such as the credit card fees charged by some airlines.
  • * Information about paid seats and other air extras has been to the `GET /bookings` response. The `totalAirExtras` object has been added within the `fare` (under `flightItineraries`). The cost of the air extras is also included in the `totalFare` and `totalFlightCost` items.
  • * The "formatted phone number" feature released in [19.04](http://corporatetravel.developer.sabre.com/blog/1904-release-notes#section-formatted-phone-number) has been updated. Now if the phone extension in the profile is empty the `extension` element will not be included in the `GET /travelers` response as part of `formattedPhoneNumbers`. And the order of the items within `formattedPhoneNumbers` has been changed to match their common usage: `countryCode`, `areaCode`, `localNumber`, and then `extension`. Additionally, if Air Connect is disabled in Site Administration then `GET /travelers` will have an empty `formattedPhoneNumbers` object.
  • * Additional validating carrier information has been added to the `GET /carts` response, when using the Amadeus GDS. First introduced in the [19.04 **release**](http://corporatetravel.developer.sabre.com/blog/1904-release-notes#section-validating-carrier), the the `validatingCarriers` array was already present in the `GET /carts` response for any alternate itineraries when using search-by-time, under `alternativeFlightItineraries`. Now the `validatingCarriers` object is also included on the traveler-selected itinerary, under `bookableFlightItineraries`. This update applies to both search-by-time and search-by-price paths.
  • * The information related to operating airline has been updated in various responses so it honors the related setting within Site Administration. Now the `operatingAirlineCode` (for non-codeshare flights) or the `operatingAirlineName` (for codeshare flights) is only included in the `GET /catalogs`, `GET /carts`, and `GET /bookings` responses when the setting under Air > Air Pages to "Display codeshare carrier information on the Flight/Equipment column on Flight Availability page?" is set to "Yes". If this is set to "No" then neither `operatingAirlineCode` or `operatingAirlineName` are included in the responses.
  • Note: Marketing airline information is always included in the `marketingAirlineCode` and `marketingAirlineName` elements of the `GET /catalogs`, `GET /carts`, and `GET /bookings` responses.
  • * If there are no RTF vouchers applicable to the itinerary, then acceptableVouchers will not be included in the `GET /catalogs` response, under `bookableFlightItineraries`.
  • * The elements `newAnswer` and `newAnswerId` - added back in [18.11](http://corporatetravel.developer.sabre.com/blog/1811-release-notes#section-custom-fields-supplementarydatagroups) - have been removed. These temporary fields are no longer needed following the update of `answer` and `answerId` in the [19.02 release](http://corporatetravel.developer.sabre.com/blog/1902-release-notes#section-enhancements-and-general-improvements).
  • * The `vouchers` data has been removed from the `GET /travelers` response. This object was never populated, and the Southwest RTF data is available from the `GET /carts` response in `acceptableVouchers`, as noted above.
  • * The irrelevant `itineraryId` element has been removed from the `GET /bookings` response.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.05
Target Audience
TN
Environment
Production

What's New

  • The 19.05 update to the Corporate Travel Services adds baggage information to flight shopping, allows Southwest RTF vouchers to be used when making a new booking, and adds support for a new type of overridable payment card that can be used with Air Connect flights. In addition this release improves error handling, adds other small enhancements, cleans up the API schemas, and squashes a few bugs.
  • Baggage allowance information has been added to the `GET /catalogs` response when using search by price, and to the `GET /**carts**` response when using search by time (but only for `alternativeFlightItineraries`). A new `flightBaggagePolicies` array describes the allowed "free bags" for an itinerary - as indicated by `feeApplies` set to "false". Three types of baggage information can be included, depending on the GDS, the market, and the airline: * Quantity. The `numberOfPieces` which are included for the fare. Example:
  • * Weight (and quantity). The `numberOfPieces` which are included for the fare, along with the `maximumWeight` (and the unit of weight).
  • * Descriptive text. Free text provided by the airline that describes the baggage restrictions for the fare. Note that `firstPiece` and `lastPiece`are not currently set correctly in this view. This will be updated in a future release.
  • Note: Baggage allowance information is only available from the latest webservice shopping options, not through older webservices or when using classic "green screen" shopping. That means only when using Amadeus' Travelboard, Sabre's Bargain Finder Max, or TravelPorts universal API.
  • Residual Travel Funds and Southwest Airlines
  • When a booking on Southwest Airlines (WN) is cancelled it can generate a Residual Travel Fund (RTF). These RTFs are a type of travel voucher managed by Southwest Airlines, and can be applied when making a future booking on the airline.
  • When a Southwest RTF is created it is added to a list of RTFs for that traveler, which is maintained in our system. When a traveler shops for their next trip on Southwest, up to five of that traveler’s RTFs (the oldest) are sent to Southwest Airlines via the Air Connect aggregator during `GET /carts` re-pricing, to confirm viability and remaining value. The information returned from Southwest is used to populate the `acceptableVouchers` section of the `GET /carts` response. This array includes a `voucherCode` which identifies each RTF, its `expirationDate`, the original value of the RTF (`initialValue`) and the available `amount` that can be applied to another booking (`currentBalance`).
  • The traveler should be presented with this RTF information as one of the possible forms of payment for the booking in progress. (Note that if a RTF is returned with a value of "0" that RTF cannot be used for a booking and should not be presented to the traveler.) The traveler can elect to use none, some, or all of the available RTFs in the booking process. To apply the RTFs towards the booking the `POST /carts/{id}/bookings` request needs to include the `paymentVouchers` object along with the selected `voucherCode`(s).
  • The `voucherCode`(s) in the request are sent to Southwest Airline (through the Air Connect aggregator). Ultimately Southwest decides which vouchers are used and how much of its value is applied to the new booking. (But normally the RTFs are used oldest to newest.) The `GET/bookings` response will identify the RTFs used for any booking under `appliedVouchers`, and includes the `amountDebited` for each RTF.
  • Helpful hints: * RTFs are only created when a “Wanna Get Away” booking is cancelled (not voided). This is a non-refundable brand from Southwest Airlines. Other brands - such as "Business Select" or "Anytime" - will generate a refund to the payment card when cancelled.
  • * The only RTFs available through the APIs are for bookings cancelled using the `PATCH /bookings` API (or the GetThere online booking tool). RTFs generated in any other way are not accessible. RTFs generated from a cancelled booking can be viewed under `issuedVouchers` in the `GET/bookings` response.
  • * A RTF can only be applied to a booking on Southwest Airlines when using Air Connect. RTFs cannot be used for a Southwest booking through a GDS. Additionally, passive segments must be enabled for Air Connect in order to make a booking with a RTF.
  • * A payment card must be included in the `POST /carts/{id}/bookings` request. A request with only RFT `voucherCode`(s) will be rejected.
  • * While up to five RTFs are sent to the Air Connect aggregator, at this time only the oldest two RTFs are sent on to Southwest. This a a limitation of the Southwest API. This API is in the process of being updated to support an additional number of RTFs. Any change to increase the number of RTFs between the aggregator and Southwest will be automatic from the viewpoint of the Corporate Travel Service APIs. But care should be taken to make sure the client's Checkout page can support up to five RTFs, as the number increases.
  • Overridable Site Card: Support has been added to the Corporate Travel Service APIs for a new "Payment Override" feature based on a new type of corporate Site Card, called an "Overridable Site Card". The "Overridable Site Card" is a placeholder for an actual payment card that will be chosen from a list of many possible payment cards, based on some defined criteria in the traveler’s profile. A form of this capability has been available for some time, but that could only be used for bookings in a GDS since the older feature relies on strings written to the PNR. This new option can be used for non-GDS bookings, such as those for Air Connect.
  • Details regarding the new payment option are detailed in documentation available from GetThere University. Use of this feature is transparent to the APIs with the exception of error handling. The following have been added to the `POST /carts/{id}/bookings` response to handle two possible situations that can arise when using this feature:
  • * The Card Type of the "Overridable Site Card" does not match the Card Type for the actual override payment card selected based on "Unique Name". In this situation an error is returned with `type` = "PAYMENT_OVERRIDE_CARD_TYPE_MISMATCH" under `category` "BAD_CONFIGURATION", with `description` "Payment override card type mismatch".
  • * A match cannot be made between the lookup value of the "Overridable Site Card" (the Profile CFE or Profile Field value) and any "Unique Name" in the table of Payment Override Charge Cards. If this happens an error of `type` = "PAYMENT_OVERRIDE_CARD_NOT_FOUND" is returned under `category` "BAD_CONFIGURATION", with `description` "Payment override card not found".
  • Note: The new "Payment Override" option can only be used in situations where a CVV is not required to complete the booking.
  • Improved Error Handling. Better categorization and additional information has been added for the following error situations: * TravelFusion error with "Results no longer available" during `GET /carts` repricing. This situation now returns error `type` = "FLIGHT_NOT_AVAILABLE" under `category` "EXPIRED_DATA", with `description` "Flight is no longer available".
  • * TravelFusion error with "Your card issuer has rejected your payment" during `POST /carts/{id}/bookings`. Now returns error `type` = "PAYMENT_DECLINED" under `category` "INVALID_DATA", with `description` "Booking cannot be made. Payment card declined. Your card issuer has rejected your payment. (Transaction not permitted to cardholder.)".
  • Other Enhancements and General Improvements. Other updates have been made to improve various Corporate Travel Services: * An issue has been fixed where the `numberOfStops` was not correct in the `GET /catalogs` response on flights from Amadeus that have a layover, but no change of flight number.
  • * A `totalFees` items has been added to the `GET /bookings` response in the `fare` section. This summarizes items such as the credit card fees charged by some airlines.
  • * Information about paid seats and other air extras has been to the `GET /bookings` response. The `totalAirExtras` object has been added within the `fare` (under `flightItineraries`). The cost of the air extras is also included in the `totalFare` and `totalFlightCost` items.
  • * The "formatted phone number" feature released in [19.04](http://corporatetravel.developer.sabre.com/blog/1904-release-notes#section-formatted-phone-number) has been updated. Now if the phone extension in the profile is empty the `extension` element will not be included in the `GET /travelers` response as part of `formattedPhoneNumbers`. And the order of the items within `formattedPhoneNumbers` has been changed to match their common usage: `countryCode`, `areaCode`, `localNumber`, and then `extension`. Additionally, if Air Connect is disabled in Site Administration then `GET /travelers` will have an empty `formattedPhoneNumbers` object.
  • * Additional validating carrier information has been added to the `GET /carts` response, when using the Amadeus GDS. First introduced in the [19.04 **release**](http://corporatetravel.developer.sabre.com/blog/1904-release-notes#section-validating-carrier), the the `validatingCarriers` array was already present in the `GET /carts` response for any alternate itineraries when using search-by-time, under `alternativeFlightItineraries`. Now the `validatingCarriers` object is also included on the traveler-selected itinerary, under `bookableFlightItineraries`. This update applies to both search-by-time and search-by-price paths.
  • * The information related to operating airline has been updated in various responses so it honors the related setting within Site Administration. Now the `operatingAirlineCode` (for non-codeshare flights) or the `operatingAirlineName` (for codeshare flights) is only included in the `GET /catalogs`, `GET /carts`, and `GET /bookings` responses when the setting under Air > Air Pages to "Display codeshare carrier information on the Flight/Equipment column on Flight Availability page?" is set to "Yes". If this is set to "No" then neither `operatingAirlineCode` or `operatingAirlineName` are included in the responses.
  • Note: Marketing airline information is always included in the `marketingAirlineCode` and `marketingAirlineName` elements of the `GET /catalogs`, `GET /carts`, and `GET /bookings` responses.
  • * If there are no RTF vouchers applicable to the itinerary, then acceptableVouchers will not be included in the `GET /catalogs` response, under `bookableFlightItineraries`.
  • * The elements `newAnswer` and `newAnswerId` - added back in [18.11](http://corporatetravel.developer.sabre.com/blog/1811-release-notes#section-custom-fields-supplementarydatagroups) - have been removed. These temporary fields are no longer needed following the update of `answer` and `answerId` in the [19.02 release](http://corporatetravel.developer.sabre.com/blog/1902-release-notes#section-enhancements-and-general-improvements).
  • * The `vouchers` data has been removed from the `GET /travelers` response. This object was never populated, and the Southwest RTF data is available from the `GET /carts` response in `acceptableVouchers`, as noted above.
  • * The irrelevant `itineraryId` element has been removed from the `GET /bookings` response.

Relase note ID: 13945


  • 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.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.04
Target Audience
TN
Environment
Production

What's New

  • 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.

Relase note ID: 13946


  • The 19.03 update to the Corporate Travel Services is focused on improved error handling, squashing bugs, and delivering enhancements.
  • Better categorization and additional information has been added for the following error situations: * `Routing session has been terminated` when another booking was completed on the same identifier. Now this scenario returns error `type` = "CATALOG_EXPIRED" under `category` "EXPIRED_DATA" with `description` "Catalog has expired. Please create new one.".
  • * `E_CANT_VERIFY_MCT` when unable to verify minimum connection time. This now returns `type` = "UNABLE_TO_BOOK" under `category` "INTERNAL_SERVER_ERROR" with `description` "Unable to verify Minimum Connection Time".
  • * Air Connect (Travelfusion) flights with insufficient connection time. Instead of `500 INTERNAL SERVER ERROR` these situations now return an error with `type` = "INSUFFICIENT_CONNECTING_TIME" under `category` "INVALID_DATA" with `description` "Insufficient connecting time between journeys".
  • * Added error for Air Connect (TravelFusion) when a flight is no longer available. This now returns `type` = "FLIGHT_NOT_AVAILABLE" under `category` "EXPIRED_DATA" with `description` "Flight is no longer available".
  • * Passport expiration date is missing from profile. This situation used to return an exception from a `GET /travelers` request with `500 INTERNAL SERVER ERROR`. Now the passport expiration date is ignored and a `GET /travelers` response is returned without any `expirationDate` element under `passport`.
  • Enhancements and General Improvements
  • Other updates have been made to improve various Corporate Travel Services: * A new `mightBeExpired` indicator as been added to the `GET /carts` response under `acceptableKnownPaymentOptions`. When true this indicates the currrent date is beyond the expiration date for the associated payment card. And the `POST /bookings` request has been updated to allow the stored expiration date of a payment card to be overwritten. A replacement date (only used for that booking) can be provided in the `expirationDate` element within `pciData` (part of the `paymentCard` object).
  • * A change has been made to the POST /catalogs request so the `fareType` is ignored when shopping on Amadeus and `classOfService` = "FIRST". This eliminates the requirement to send a `null` or empty `fareType` in this situation - revising the limitation described at the end of the [19.02 Release Notes](http://corporatetravel.developer.sabre.com/blog/1902-release-notes#section-enhancements-and-general-improvements), under "Special considerations with Amadeus".
  • * The `quotedPrice` of the fare in the PCC currency is now properly passed through the services so a booking will be made using the correct price. Previously it was possible for that price to be converted to another currency, leading to unwanted behavior such as purchasing a more expensive flight or not completing the booking. This resolves a problem that required a workaround by updating the site's currency in Site Administration to match the currency setting for the PCC.
  • * `supplementaryDataQuestions` using a `constrainedResponse` are now handled by `GET /carts` (and `POST /bookings`) when `preDefinedAnswers` has an `answer` without any `answerId`. The common example of this situation is when “Please select” or similar text appears at the top of a `preDefinedAnswers` list. The “Please select” choice has an `answer` for display to the traveler, but no `answerId` for the booking. This case was resulting in an error response of `500 INTERNAL SERVER ERROR` from `GET /carts`. Now the response is returned, including those options without an `answerId`. In addition, `POST /bookings` has been updated so requests are handled properly when they involve `supplementaryData` and a `constrainedResponse` where a `null` or empty `answerId` is possible.
  • Note: Options from `GET /carts` without an `answerId` should be treated as *placeholders* or *headings* for the actual, valid choices. The traveler should be prompted to select an option with an `answerId`, so that information can be included in the `POST /bookings` request when the `supplementaryDataQuestionId` is required to complete the booking (i.e., `answerRequired` = "true").
  • * Total cost information has been added to the `GET /bookings` response. Objects for `totalFlightCost`, `totalCarCost`, `totalHotelCost`, and `totalTripCost` are now included. These "total cost" items will always provide a tally of `localizedPrice`, and will also summarize the `quotedPrice` when all parts of that component are in the same quoted currency. The `isCancelable` indicator is also now present in the `GET /bookings` response. (Note that `totalFlightCost`, `totalTripCost`, and `isCancelable` were already defined in the schema for `GET /bookings` but were not populated with data.)
  • Note: Important ... the `totalTripCost` object is changing its name to `totalBookingCost` in the next release.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.03
Target Audience
TN
Environment
Production

What's New

  • The 19.03 update to the Corporate Travel Services is focused on improved error handling, squashing bugs, and delivering enhancements.
  • Better categorization and additional information has been added for the following error situations: * `Routing session has been terminated` when another booking was completed on the same identifier. Now this scenario returns error `type` = "CATALOG_EXPIRED" under `category` "EXPIRED_DATA" with `description` "Catalog has expired. Please create new one.".
  • * `E_CANT_VERIFY_MCT` when unable to verify minimum connection time. This now returns `type` = "UNABLE_TO_BOOK" under `category` "INTERNAL_SERVER_ERROR" with `description` "Unable to verify Minimum Connection Time".
  • * Air Connect (Travelfusion) flights with insufficient connection time. Instead of `500 INTERNAL SERVER ERROR` these situations now return an error with `type` = "INSUFFICIENT_CONNECTING_TIME" under `category` "INVALID_DATA" with `description` "Insufficient connecting time between journeys".
  • * Added error for Air Connect (TravelFusion) when a flight is no longer available. This now returns `type` = "FLIGHT_NOT_AVAILABLE" under `category` "EXPIRED_DATA" with `description` "Flight is no longer available".
  • * Passport expiration date is missing from profile. This situation used to return an exception from a `GET /travelers` request with `500 INTERNAL SERVER ERROR`. Now the passport expiration date is ignored and a `GET /travelers` response is returned without any `expirationDate` element under `passport`.
  • Enhancements and General Improvements
  • Other updates have been made to improve various Corporate Travel Services: * A new `mightBeExpired` indicator as been added to the `GET /carts` response under `acceptableKnownPaymentOptions`. When true this indicates the currrent date is beyond the expiration date for the associated payment card. And the `POST /bookings` request has been updated to allow the stored expiration date of a payment card to be overwritten. A replacement date (only used for that booking) can be provided in the `expirationDate` element within `pciData` (part of the `paymentCard` object).
  • * A change has been made to the POST /catalogs request so the `fareType` is ignored when shopping on Amadeus and `classOfService` = "FIRST". This eliminates the requirement to send a `null` or empty `fareType` in this situation - revising the limitation described at the end of the [19.02 Release Notes](http://corporatetravel.developer.sabre.com/blog/1902-release-notes#section-enhancements-and-general-improvements), under "Special considerations with Amadeus".
  • * The `quotedPrice` of the fare in the PCC currency is now properly passed through the services so a booking will be made using the correct price. Previously it was possible for that price to be converted to another currency, leading to unwanted behavior such as purchasing a more expensive flight or not completing the booking. This resolves a problem that required a workaround by updating the site's currency in Site Administration to match the currency setting for the PCC.
  • * `supplementaryDataQuestions` using a `constrainedResponse` are now handled by `GET /carts` (and `POST /bookings`) when `preDefinedAnswers` has an `answer` without any `answerId`. The common example of this situation is when “Please select” or similar text appears at the top of a `preDefinedAnswers` list. The “Please select” choice has an `answer` for display to the traveler, but no `answerId` for the booking. This case was resulting in an error response of `500 INTERNAL SERVER ERROR` from `GET /carts`. Now the response is returned, including those options without an `answerId`. In addition, `POST /bookings` has been updated so requests are handled properly when they involve `supplementaryData` and a `constrainedResponse` where a `null` or empty `answerId` is possible.
  • Note: Options from `GET /carts` without an `answerId` should be treated as *placeholders* or *headings* for the actual, valid choices. The traveler should be prompted to select an option with an `answerId`, so that information can be included in the `POST /bookings` request when the `supplementaryDataQuestionId` is required to complete the booking (i.e., `answerRequired` = "true").
  • * Total cost information has been added to the `GET /bookings` response. Objects for `totalFlightCost`, `totalCarCost`, `totalHotelCost`, and `totalTripCost` are now included. These "total cost" items will always provide a tally of `localizedPrice`, and will also summarize the `quotedPrice` when all parts of that component are in the same quoted currency. The `isCancelable` indicator is also now present in the `GET /bookings` response. (Note that `totalFlightCost`, `totalTripCost`, and `isCancelable` were already defined in the schema for `GET /bookings` but were not populated with data.)
  • Note: Important ... the `totalTripCost` object is changing its name to `totalBookingCost` in the next release.

Relase note ID: 13947


  • The 19.02 update to the Corporate Travel Services is focused on improved error handling, squashing bugs, and delivering enhancements.
  • This release is officially known as 19.02-01 since it is a patch release to 19.02. The 19.02 update on 5 March introduced a problem related to the setting which allows the traveler's name to be changed at the time of booking. A workaround involving system settings minimized the impact of the issue until it was corrected with an update on 13 March. The changes in the 19.02-01 update were internal and as such did not change or affect any of the client-facing updates listed below for 19.02.
  • Improved error handling. Better categorization and additional information has been added for the following situations involving a `POST / bookings` request sent to Agentware (one of the Air Connect aggregators/suppliers). In each of these cases the API previously returned `INTERNAL_SERVER_ERROR` (500):
  • * Invalid phone number (for example, when the number includes an alpha character). Now returns error `type` = "INVALID_PHONE_NUMBER" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Phone number is invalid.".
  • * Invalid email address. Now returns error `type` = "INVALID_EMAIL" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Invalid email.".
  • * Expired payment card. Now returns error `type` = "PAYMENT_CARD_EXPIRED" under `category` "INVALID_DATA" with `description` "Booking cannot be made. **Payment **card has expired.".
  • * Declined payment card or general error processing the payment card. Both scenarios now return error `type` = "PAYMENT_DECLINED" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Payment card declined.".
  • Enhancements and General Improvements. Other updates have been made to improve various Corporate Travel Services: * Corrected a problem where the PNR Editor Tag `itin.has_air_tempcard` was not set correctly. This Tag now has the correct state and can be used in PNR Editor Strings as part of an expression to create a PNR remark.
  • * Added the ability to send replacement (override) traveler contact information (`contactInfo`) with `emailAddress` and/or `telephoneNumber` in a `POST /bookings` request.
  • * Removed `fareRulesId` from the `GET /catalogs` response for Air Connect flights. This is a continuation of the plan described in the [18.09 Release Notes](http://corporatetravel.developer.sabre.com/blog/1809-release-notes#section-farebrands-service) to migrate to the `GET /fareBrands` service for brand attribute data, and remove brand information from the `GET /fareRules` response.
  • * A payment card `billingAddress` object has been added for each card under `acceptableKnownPaymentOptions` in `GET /carts`. This information is aligned with the `isBillingAddressInProfile` indicator also present for each payment card. Note that every payment billing address has four required elements: `addressLine1`, `city`, `postalCode`, and `countryCode`:
  • * If any of the required elements for the payment billing address are empty then the `billingAddress` object will be `null` and `isBillingAddressInProfile` will be `false`.
  • * All of the required elements must have a value for the `billingAddress` object to be populated and for `isBillingAddressInProfile` to be `true`.
  • * When `isBillingAddressInProfile` is `true` then the optional elements `addressLine2` and `stateProvinceCode` will also be included, whenever either element is not empty.
  • * Fixed the issue noted in the [18.11-01 Release Notes](http://corporatetravel.developer.sabre.com/blog/1811-01-release-notes#section-personal-address) where `stateProvinceCode` was a required element for Air Connect bookings, whenever address was included in a `POST /bookings` request. The `stateProvinceCode` is no longer required in `POST /bookings` for countries without such information.
  • * Improved the handling of situations where a booking completed successfully but some informational components were not returned from the supplier (e.g. vendor confirmation). This sometimes caused a response of `INTERNAL_SERVER_ERROR` (500) from `POST /bookings`, leaving the traveler unclear if the booking was or was not complete. These situations will now be handled properly, without an error.
  • * Updated the `GET bookings` response to return `travelerId` in the correct format (the same as in the `POST /bookings` request). Also replaced some elements under `travelers` and `personalIdentifiableInformation` with names that better describe their contents - matching the booking information as stored in the GDS. Specifically, `firstName` and `middleName` have been replaced by `givenName` with both pieces of data, and `lastName` is now surname.
  • * The `supplementaryDataQuestions` array has been removed from the `GET /travelers` response. This information is now only available from the `GET /carts` response. This update implements the vision for `GET /carts` functionality described back in late 2017 in the notes for [Upcoming: Air Connect and Cart Service](http://corporatetravel.developer.sabre.com/blog/upcoming-air-connect-and-cart-service#section-get-cart-functionality).
  • * Updated several services so `travelerId` can include a period (.) character, such as when the `travelerId` in an email address.
  • * As foretold in the [18.11 Release Notes](http://corporatetravel.developer.sabre.com/blog/1811-release-notes#section-custom-fields-supplementarydatagroups), the contents of `answerId` and `answer` have been swapped. Now `answer` is the "label" shown to the traveler and `answerId` is the "code" or value for the selection.
  • Warning! Clients should stop using `newAnswer` and `newAnswerId`, and return to using `answer` and `answerId`. The `newAnswer` and `newAnswerId` elements will be removed from `GET /carts` in a future update.
  • * Information about class of service has been added into the `GET /sites` response. This data identifies which classes are configured for use on the site-subsite - such as Coach, Premium Economy, Business, or First. The response includes an array of `shoppableClassesOfService` within `airConfiguration`. Each grouping under `shoppableClassesOfService` describes a `classOfService`, the `label` configured for that `classOfService`, and an `isDefault` boolean indicator to identify which `classOfService` is setup as the default.
  • Note: This new `shoppableClassesOfService` array in `GET /sites` works in conjunction with the `shoppableFareTypes` array introduced in release 18.11.
  • Special considerations with Amadeus. Sites using the Amadeus GDS have an alternate configuration in Site Administration, such that supported classes of service are setup together with fare types, rather than independently. In addition only the LOWEST_AVAILABLE and UNRESTRICTED fare types are supported, and only for some classes of service. Because of these unique aspects the following needs to be considered when using an Amadeus site:
  • `>` Only LOWEST_AVAILABLE and/or UNRESTRICTED will be returned under `shoppableFareTypes` in `GET /sites`.
  • `>` The `label` element is not present in the `GET /sites` response for either `shoppableClassesOfService` or `shoppableFareTypes`.
  • `>` If LOWEST_AVAILABLE and UNRESTRICTED are listed as `shoppableFareTypes` in `GET /sites` they can be used as `fareType` when flight shopping with `POST /catalogs` - but only with the COACH, PREMIUM_ECONOMY, or BUSINESS `classOfService`. However, it is possible to configure a given `fareType` so it is allowed for one `classOfService` but not for another `classOfService`. For example, UNRESTRICTED can be configured for use when shopping COACH, but not allowed when shopping BUSINESS. Currently these types of special configurations that link just *some* `shoppableFareTypes` to *some* `shoppableClassesOfService` are not described in the `GET /sites` response.
  • `>` When shopping for the FIRST `classOfService` with `POST /catalogs` there is no assigned `fareType`. So the `fareType` element must equal `null` or be removed entirely from the `POST /catalogs` request. (*Be sure to see an update to this behavior described in the* [19.03 Release Notes](http://corporatetravel.developer.sabre.com/v1.0/blog/1903-release-notes#section-enhancements-and-general-improvements).)

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.02
Target Audience
TN
Environment
Production

What's New

  • The 19.02 update to the Corporate Travel Services is focused on improved error handling, squashing bugs, and delivering enhancements.
  • This release is officially known as 19.02-01 since it is a patch release to 19.02. The 19.02 update on 5 March introduced a problem related to the setting which allows the traveler's name to be changed at the time of booking. A workaround involving system settings minimized the impact of the issue until it was corrected with an update on 13 March. The changes in the 19.02-01 update were internal and as such did not change or affect any of the client-facing updates listed below for 19.02.
  • Improved error handling. Better categorization and additional information has been added for the following situations involving a `POST / bookings` request sent to Agentware (one of the Air Connect aggregators/suppliers). In each of these cases the API previously returned `INTERNAL_SERVER_ERROR` (500):
  • * Invalid phone number (for example, when the number includes an alpha character). Now returns error `type` = "INVALID_PHONE_NUMBER" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Phone number is invalid.".
  • * Invalid email address. Now returns error `type` = "INVALID_EMAIL" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Invalid email.".
  • * Expired payment card. Now returns error `type` = "PAYMENT_CARD_EXPIRED" under `category` "INVALID_DATA" with `description` "Booking cannot be made. **Payment **card has expired.".
  • * Declined payment card or general error processing the payment card. Both scenarios now return error `type` = "PAYMENT_DECLINED" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Payment card declined.".
  • Enhancements and General Improvements. Other updates have been made to improve various Corporate Travel Services: * Corrected a problem where the PNR Editor Tag `itin.has_air_tempcard` was not set correctly. This Tag now has the correct state and can be used in PNR Editor Strings as part of an expression to create a PNR remark.
  • * Added the ability to send replacement (override) traveler contact information (`contactInfo`) with `emailAddress` and/or `telephoneNumber` in a `POST /bookings` request.
  • * Removed `fareRulesId` from the `GET /catalogs` response for Air Connect flights. This is a continuation of the plan described in the [18.09 Release Notes](http://corporatetravel.developer.sabre.com/blog/1809-release-notes#section-farebrands-service) to migrate to the `GET /fareBrands` service for brand attribute data, and remove brand information from the `GET /fareRules` response.
  • * A payment card `billingAddress` object has been added for each card under `acceptableKnownPaymentOptions` in `GET /carts`. This information is aligned with the `isBillingAddressInProfile` indicator also present for each payment card. Note that every payment billing address has four required elements: `addressLine1`, `city`, `postalCode`, and `countryCode`:
  • * If any of the required elements for the payment billing address are empty then the `billingAddress` object will be `null` and `isBillingAddressInProfile` will be `false`.
  • * All of the required elements must have a value for the `billingAddress` object to be populated and for `isBillingAddressInProfile` to be `true`.
  • * When `isBillingAddressInProfile` is `true` then the optional elements `addressLine2` and `stateProvinceCode` will also be included, whenever either element is not empty.
  • * Fixed the issue noted in the [18.11-01 Release Notes](http://corporatetravel.developer.sabre.com/blog/1811-01-release-notes#section-personal-address) where `stateProvinceCode` was a required element for Air Connect bookings, whenever address was included in a `POST /bookings` request. The `stateProvinceCode` is no longer required in `POST /bookings` for countries without such information.
  • * Improved the handling of situations where a booking completed successfully but some informational components were not returned from the supplier (e.g. vendor confirmation). This sometimes caused a response of `INTERNAL_SERVER_ERROR` (500) from `POST /bookings`, leaving the traveler unclear if the booking was or was not complete. These situations will now be handled properly, without an error.
  • * Updated the `GET bookings` response to return `travelerId` in the correct format (the same as in the `POST /bookings` request). Also replaced some elements under `travelers` and `personalIdentifiableInformation` with names that better describe their contents - matching the booking information as stored in the GDS. Specifically, `firstName` and `middleName` have been replaced by `givenName` with both pieces of data, and `lastName` is now surname.
  • * The `supplementaryDataQuestions` array has been removed from the `GET /travelers` response. This information is now only available from the `GET /carts` response. This update implements the vision for `GET /carts` functionality described back in late 2017 in the notes for [Upcoming: Air Connect and Cart Service](http://corporatetravel.developer.sabre.com/blog/upcoming-air-connect-and-cart-service#section-get-cart-functionality).
  • * Updated several services so `travelerId` can include a period (.) character, such as when the `travelerId` in an email address.
  • * As foretold in the [18.11 Release Notes](http://corporatetravel.developer.sabre.com/blog/1811-release-notes#section-custom-fields-supplementarydatagroups), the contents of `answerId` and `answer` have been swapped. Now `answer` is the "label" shown to the traveler and `answerId` is the "code" or value for the selection.
  • Warning! Clients should stop using `newAnswer` and `newAnswerId`, and return to using `answer` and `answerId`. The `newAnswer` and `newAnswerId` elements will be removed from `GET /carts` in a future update.
  • * Information about class of service has been added into the `GET /sites` response. This data identifies which classes are configured for use on the site-subsite - such as Coach, Premium Economy, Business, or First. The response includes an array of `shoppableClassesOfService` within `airConfiguration`. Each grouping under `shoppableClassesOfService` describes a `classOfService`, the `label` configured for that `classOfService`, and an `isDefault` boolean indicator to identify which `classOfService` is setup as the default.
  • Note: This new `shoppableClassesOfService` array in `GET /sites` works in conjunction with the `shoppableFareTypes` array introduced in release 18.11.
  • Special considerations with Amadeus. Sites using the Amadeus GDS have an alternate configuration in Site Administration, such that supported classes of service are setup together with fare types, rather than independently. In addition only the LOWEST_AVAILABLE and UNRESTRICTED fare types are supported, and only for some classes of service. Because of these unique aspects the following needs to be considered when using an Amadeus site:
  • `>` Only LOWEST_AVAILABLE and/or UNRESTRICTED will be returned under `shoppableFareTypes` in `GET /sites`.
  • `>` The `label` element is not present in the `GET /sites` response for either `shoppableClassesOfService` or `shoppableFareTypes`.
  • `>` If LOWEST_AVAILABLE and UNRESTRICTED are listed as `shoppableFareTypes` in `GET /sites` they can be used as `fareType` when flight shopping with `POST /catalogs` - but only with the COACH, PREMIUM_ECONOMY, or BUSINESS `classOfService`. However, it is possible to configure a given `fareType` so it is allowed for one `classOfService` but not for another `classOfService`. For example, UNRESTRICTED can be configured for use when shopping COACH, but not allowed when shopping BUSINESS. Currently these types of special configurations that link just *some* `shoppableFareTypes` to *some* `shoppableClassesOfService` are not described in the `GET /sites` response.
  • `>` When shopping for the FIRST `classOfService` with `POST /catalogs` there is no assigned `fareType`. So the `fareType` element must equal `null` or be removed entirely from the `POST /catalogs` request. (*Be sure to see an update to this behavior described in the* [19.03 Release Notes](http://corporatetravel.developer.sabre.com/v1.0/blog/1903-release-notes#section-enhancements-and-general-improvements).)

Relase note ID: 13948


  • ## The 19.01 update to the Corporate Travel Services is focused on improved error handling, squashing bugs, and delivering a few enhancements.
  • Note: This release is officially known as 19.01-01 since it is a patch release to 19.01. The 19.01 update was briefly put into production on 30 January 2019, but was quickly removed after an issue was found with a new system used to authorize API access. The 19.01-01 release on 7 February provides the exact same client-facing updates that were noted for 19.01, but does not use the new authorization system (instead it uses the same authorization in previously releases).
  • Improved error handling. Better categorization and additional information has been added for the following situations: * `E_NEED_TICKETING` (`error_code: 175`). Now returns error `type` = "INVALID_TICKETING_DATA" under `category` "BAD_CONFIGURATION" with `description` = "Invalid or missing ticketing time limit.".
  • * `E_NEED ADDRESS` (`error_code: 108`). Now returns **error **`type` = "INVALID_PROFILE_ON_SUPPLIER_SIDE" under `category` "BAD_CONFIGURATION".
  • * `E_BILLING_NAME_ERROR` (`error_code: 69`). Now returns an error under `category` "BAD_CONFIGURATION" with `description` = "Unable to complete booking.".
  • * `PAYMENT_CARD_NOT_FOUND` (`error_code: 23`). Three specific types of payment errors have been broken down to provide more information. These cases now return a different error `type` and `description` under `category` "INVALID_DATA", depending on the issue:
  • * `type` = "PAYMENT_CARD_EXPIRED" with `description` = "Booking cannot be made. Payment card has expired."
  • * `type` = "INVALID_PAYMENT_CARD_NUMBER" with `description` = "Booking cannot be made. Invalid card number."
  • * `type` = "INVALID_PAYMENT_CARD_SECURITY_CODE" with `description` = "Booking cannot be made. Invalid security code."
  • ## * `[[CREDIT_CARD_EXPIRED](from Air **Connect **(*TravelFusion*). Previously this returned `INTERNAL_SERVER_ERROR` (500) but now returns error `type` = "PAYMENT_CARD_EXPIRED" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Payment card has expired.".
  • * Missing or duplicate shopping parameters. If neither `shopByPrice` or `shopByTime` are included in the `POST /catalogs` request (or if they are both included) a new error is returned with `type` = "EXACTLY_ONE_FIELD_REQUIRED" under the `category` "BAD_REQUEST" with `description` = "Exactly one of shopByPrice or shopByTime fields must be provided".
  • Enhancements and General Improvements. Other updates have been made to improve various Corporate Travel Services: * Retired the ability to book without a Cart. This means `POST /bookings` can no longer be used. All bookings must be made using `POST /carts/{id}/bookings`.
  • * Preferred airlines sometimes showed `corporatePreference` = "true" in the Catalog, but the same setting was "false" in the Cart. This has been fixed so preferred airlines are always identified as `corporatePreference` = "true" in both the Catalog and the Cart.
  • * The traveler's `assignedSiteId` has been added to the `GET /travelers` response. This identifies the site and subsite to which the traveler's login is assigned within the system. The `siteId` element is still present and denotes the "working" site and subsite for the traveler to be used during their session. This will be different from `assignedSiteId` if API Subsite Redirection is enabled.
  • * Fixed the issue noted in the [18.11 Release Notes](http://corporatetravel.developer.sabre.com/blog/1811-release-notes#section-booking-details) where the `localizedPrice` in `GET /bookings` used the same currency and value as `quotedPrice`. The proper currencies are now listed, with the converted amounts for that currency. This same update was also made to the `GET /catalogs` and `GET /carts` responses when using the Search by Time path.
  • * Added a `specialRequests` array to the `GET /bookings` response within `carItineraries` identifying any special equipment requests associated with the vehicle included in the booking.
  • * The list of `suppliers` from `GET /sites` included data from the SuperPNR setting for secondary suppliers even when SuperPNR was disabled in Site Administration. Now that information is only included in `GET /sites` when SuperPNR is enabled.
  • * Summary details have been added to the `GET /travelers/bookings` and `GET /bookings` responses. Specifically the trip `startDate`, `endDate`, and `destinationName` (city).
  • * Corrected a problem where `GET /carts` returned a 422 error when going down the Search by Time path and an `itemType` = "FLIGHT_SEAT" was in the Cart. Now the Cart is priced correctly when a seat is included.
  • * Added support for hidden and read-only custom fields (CFEs) - referred to as `supplementaryDataQuestions` in the webservices. Now hidden (`toBeConcealed`) and read-only (`readOnly`) fields are included in `GET /carts` and are validated in `POST /carts/bookings`. More information is available in the updated documentation on `supplementaryDataGroups` and `supplementaryDataQuestions`. ***<<-- Need to add link to location when documentation is updated.***
  • * Converted `numberOfConnectionsAllowed` from a value to an enum in the `GET /sites` response in order to accommodate a couple of special options that use non-standard values. This setting identifies the type of connecting flight options to be included in the air shopping response. When a site was configured in Site Administration with one of the special options it caused `GET /sites` to return an error. That no longer happens. The enums for this element can be:
  • ALL_RESULTS: all available journeys. NON_STOP_AND_DIRECT_FLIGHTS_ONLY: journeys without any connections. MAXIMUM_ONE: journeys with a maximum of one connection. MAXIMUM_TWO: journeys with a maximum of two connections. MAXIMUM_THREE: Journeys with a maximum of three connections

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.19.01
Target Audience
TN
Environment
Production

What's New

  • ## The 19.01 update to the Corporate Travel Services is focused on improved error handling, squashing bugs, and delivering a few enhancements.
  • Note: This release is officially known as 19.01-01 since it is a patch release to 19.01. The 19.01 update was briefly put into production on 30 January 2019, but was quickly removed after an issue was found with a new system used to authorize API access. The 19.01-01 release on 7 February provides the exact same client-facing updates that were noted for 19.01, but does not use the new authorization system (instead it uses the same authorization in previously releases).
  • Improved error handling. Better categorization and additional information has been added for the following situations: * `E_NEED_TICKETING` (`error_code: 175`). Now returns error `type` = "INVALID_TICKETING_DATA" under `category` "BAD_CONFIGURATION" with `description` = "Invalid or missing ticketing time limit.".
  • * `E_NEED ADDRESS` (`error_code: 108`). Now returns **error **`type` = "INVALID_PROFILE_ON_SUPPLIER_SIDE" under `category` "BAD_CONFIGURATION".
  • * `E_BILLING_NAME_ERROR` (`error_code: 69`). Now returns an error under `category` "BAD_CONFIGURATION" with `description` = "Unable to complete booking.".
  • * `PAYMENT_CARD_NOT_FOUND` (`error_code: 23`). Three specific types of payment errors have been broken down to provide more information. These cases now return a different error `type` and `description` under `category` "INVALID_DATA", depending on the issue:
  • * `type` = "PAYMENT_CARD_EXPIRED" with `description` = "Booking cannot be made. Payment card has expired."
  • * `type` = "INVALID_PAYMENT_CARD_NUMBER" with `description` = "Booking cannot be made. Invalid card number."
  • * `type` = "INVALID_PAYMENT_CARD_SECURITY_CODE" with `description` = "Booking cannot be made. Invalid security code."
  • ## * `[[CREDIT_CARD_EXPIRED](from Air **Connect **(*TravelFusion*). Previously this returned `INTERNAL_SERVER_ERROR` (500) but now returns error `type` = "PAYMENT_CARD_EXPIRED" under `category` "INVALID_DATA" with `description` "Booking cannot be made. Payment card has expired.".
  • * Missing or duplicate shopping parameters. If neither `shopByPrice` or `shopByTime` are included in the `POST /catalogs` request (or if they are both included) a new error is returned with `type` = "EXACTLY_ONE_FIELD_REQUIRED" under the `category` "BAD_REQUEST" with `description` = "Exactly one of shopByPrice or shopByTime fields must be provided".
  • Enhancements and General Improvements. Other updates have been made to improve various Corporate Travel Services: * Retired the ability to book without a Cart. This means `POST /bookings` can no longer be used. All bookings must be made using `POST /carts/{id}/bookings`.
  • * Preferred airlines sometimes showed `corporatePreference` = "true" in the Catalog, but the same setting was "false" in the Cart. This has been fixed so preferred airlines are always identified as `corporatePreference` = "true" in both the Catalog and the Cart.
  • * The traveler's `assignedSiteId` has been added to the `GET /travelers` response. This identifies the site and subsite to which the traveler's login is assigned within the system. The `siteId` element is still present and denotes the "working" site and subsite for the traveler to be used during their session. This will be different from `assignedSiteId` if API Subsite Redirection is enabled.
  • * Fixed the issue noted in the [18.11 Release Notes](http://corporatetravel.developer.sabre.com/blog/1811-release-notes#section-booking-details) where the `localizedPrice` in `GET /bookings` used the same currency and value as `quotedPrice`. The proper currencies are now listed, with the converted amounts for that currency. This same update was also made to the `GET /catalogs` and `GET /carts` responses when using the Search by Time path.
  • * Added a `specialRequests` array to the `GET /bookings` response within `carItineraries` identifying any special equipment requests associated with the vehicle included in the booking.
  • * The list of `suppliers` from `GET /sites` included data from the SuperPNR setting for secondary suppliers even when SuperPNR was disabled in Site Administration. Now that information is only included in `GET /sites` when SuperPNR is enabled.
  • * Summary details have been added to the `GET /travelers/bookings` and `GET /bookings` responses. Specifically the trip `startDate`, `endDate`, and `destinationName` (city).
  • * Corrected a problem where `GET /carts` returned a 422 error when going down the Search by Time path and an `itemType` = "FLIGHT_SEAT" was in the Cart. Now the Cart is priced correctly when a seat is included.
  • * Added support for hidden and read-only custom fields (CFEs) - referred to as `supplementaryDataQuestions` in the webservices. Now hidden (`toBeConcealed`) and read-only (`readOnly`) fields are included in `GET /carts` and are validated in `POST /carts/bookings`. More information is available in the updated documentation on `supplementaryDataGroups` and `supplementaryDataQuestions`. ***<<-- Need to add link to location when documentation is updated.***
  • * Converted `numberOfConnectionsAllowed` from a value to an enum in the `GET /sites` response in order to accommodate a couple of special options that use non-standard values. This setting identifies the type of connecting flight options to be included in the air shopping response. When a site was configured in Site Administration with one of the special options it caused `GET /sites` to return an error. That no longer happens. The enums for this element can be:
  • ALL_RESULTS: all available journeys. NON_STOP_AND_DIRECT_FLIGHTS_ONLY: journeys without any connections. MAXIMUM_ONE: journeys with a maximum of one connection. MAXIMUM_TWO: journeys with a maximum of two connections. MAXIMUM_THREE: Journeys with a maximum of three connections

Relase note ID: 13949


  • The 18.11-01 update to the Corporate Travel Services adds enhancements around a traveler's personal address, providing a way to determine if a traveler has an address in their profile and allowing this information to be included in booking requests.
  • Personal Address. Most Air Connect carriers require a traveler's personal address to complete a booking. This address information is usually in a traveler's profile. But when there is no such address in the profile a booking cannot be made with Air Connect. To allow Air Connect bookings to still be made when there is no personal address in the profile several endpoints have been enhanced:
  • * `GET /travelers`. The response to this API now includes the address from the traveler's profile. This allows the Corporate Travel Services client to determine when a traveler needs to provide address information during the checkout process, for inclusion with the booking. A new `address` collection includes elements for `addressLine1`, `addressLine2`, `city`, `stateProvinceCode`, `postalCode`, and `countryCode`. For most of the elements empty strings are returned when there is no value. The exceptions are `addressLine2` and `stateProvinceCode`. If either of these is empty then that element is simply not included. And if there are no values for any of these elements from the traveler's profile, then `address` is not returned in the response.
  • * `POST /bookings`. An `address` collection with a traveler's personal address can now be added to the booking request under `travelers`, `personalIdentifiableInformation`. The same elements listed above should be included. For Air Connect bookings all of the elements are required except for `addressLine2`, and none of the elements can be empty. Address information can optionally be included with non-Air Connect bookings too (i.e. bookings through the GDS). In that case all of the elements are required except `addressLine2` and `stateProvinceCode`; and for these types of booking requests empty values are allowed. In addition, validation of the personal address has been added when a booking is for Air Connect. If any required address elements are empty in the traveler's profile and no `address` has been provided in the booking request, then an error is returned with `type` = "INVALID_PROFILE_ADDRESS" under the `category` of "INVALID_DATA". The same error is returned if `address` is in
  • * `GET /bookings`. When a personal address is included in a booking request or pulled from the traveler's profile, that information is now included in the `GET /bookings` response in an `address` collection under `travelers`, `personalIdentifiableInformation`. The same elements already mentioned are provided. Most elements will include an empty string if there is no data. As with `GET /travelers`, `addressLine2` and `stateProvinceCode` are optional and will be missing from the response if they are empty.
  • Warning! Currently `stateProvinceCode` is a required element for Air Connect bookings when `address` is included in a `POST /bookings` request. For countries that do not have a standard state or province code a value of "XXX" should be submitted. This will be revised In a future update so `stateProvinceCode` is only required when needed - for countries where that information is appropriate.
  • Note: Note that the entire block of address information must come from the traveler's profile or be included in the `POST /bookings` request. It is not possible to "override" selected portions of the profile address in the booking request in an attempt to "mix" data from both sources. If an `address` is included in the booking request then it must be complete, with the required elements noted above. The information in the booking `POST /bookings` request will be used whenever it is provided, replacing all of the data from the traveler's profile.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.11.1
Target Audience
TN
Environment
Production

What's New

  • The 18.11-01 update to the Corporate Travel Services adds enhancements around a traveler's personal address, providing a way to determine if a traveler has an address in their profile and allowing this information to be included in booking requests.
  • Personal Address. Most Air Connect carriers require a traveler's personal address to complete a booking. This address information is usually in a traveler's profile. But when there is no such address in the profile a booking cannot be made with Air Connect. To allow Air Connect bookings to still be made when there is no personal address in the profile several endpoints have been enhanced:
  • * `GET /travelers`. The response to this API now includes the address from the traveler's profile. This allows the Corporate Travel Services client to determine when a traveler needs to provide address information during the checkout process, for inclusion with the booking. A new `address` collection includes elements for `addressLine1`, `addressLine2`, `city`, `stateProvinceCode`, `postalCode`, and `countryCode`. For most of the elements empty strings are returned when there is no value. The exceptions are `addressLine2` and `stateProvinceCode`. If either of these is empty then that element is simply not included. And if there are no values for any of these elements from the traveler's profile, then `address` is not returned in the response.
  • * `POST /bookings`. An `address` collection with a traveler's personal address can now be added to the booking request under `travelers`, `personalIdentifiableInformation`. The same elements listed above should be included. For Air Connect bookings all of the elements are required except for `addressLine2`, and none of the elements can be empty. Address information can optionally be included with non-Air Connect bookings too (i.e. bookings through the GDS). In that case all of the elements are required except `addressLine2` and `stateProvinceCode`; and for these types of booking requests empty values are allowed. In addition, validation of the personal address has been added when a booking is for Air Connect. If any required address elements are empty in the traveler's profile and no `address` has been provided in the booking request, then an error is returned with `type` = "INVALID_PROFILE_ADDRESS" under the `category` of "INVALID_DATA". The same error is returned if `address` is in
  • * `GET /bookings`. When a personal address is included in a booking request or pulled from the traveler's profile, that information is now included in the `GET /bookings` response in an `address` collection under `travelers`, `personalIdentifiableInformation`. The same elements already mentioned are provided. Most elements will include an empty string if there is no data. As with `GET /travelers`, `addressLine2` and `stateProvinceCode` are optional and will be missing from the response if they are empty.
  • Warning! Currently `stateProvinceCode` is a required element for Air Connect bookings when `address` is included in a `POST /bookings` request. For countries that do not have a standard state or province code a value of "XXX" should be submitted. This will be revised In a future update so `stateProvinceCode` is only required when needed - for countries where that information is appropriate.
  • Note: Note that the entire block of address information must come from the traveler's profile or be included in the `POST /bookings` request. It is not possible to "override" selected portions of the profile address in the booking request in an attempt to "mix" data from both sources. If an `address` is included in the booking request then it must be complete, with the required elements noted above. The information in the booking `POST /bookings` request will be used whenever it is provided, replacing all of the data from the traveler's profile.

Relase note ID: 13950


  • Several customer-requested enhancements are included in this release: * The `GET /travelers` API now supports the new "API Subsite Redirect" feature just added to GetThere. This configuration option - setup in GetThere Site Administration - allows travelers coming in via the Corporate Travel Services to be "redirected" to an alternate subsite, rather than the subsite they normally connect to when logging into the GetThere OBT.
  • * The `POST /catalogs` request now supports the ability to search by arrival time instead of departure time. To allow this a few new optional parameters have been added to the API. When shopping for one-way flights the new parameter `dateTimeType` is available. For round-trip shopping there are `departDateTimeType` and `returnDateTimeType`. These new parameters can be set to either `TAKEOFF` (search by departure time) or `LANDING` (search by arrival time). If these optional parameters are not included the shop is treated as `TAKEOFF`.
  • * Information about fare type options has been added into the `GET /sites` response. This data identifies which fare types are configured for use on the site-subsite - such as lowest available, no advance purchase, no penalty, or unrestricted. The response includes an array of `shoppableFareTypes` within `airConfiguration`. Each grouping within `shoppableFareTypes` describes a `fareType`, the `label` configured for that `fareType`, and an `isDefault` boolean indicator to identify which `fareType` is to be used as the default.
  • Some enhancements and updates have been made to the `GET /bookings` response: * A `siteId` element has been added. This element identifies the site and subsite which "owns" the booking. This information will be needed in the future once bookings can be modified through the Corporate Travel Services. This data will be used to ensure the configuration parameters and messages from the "owning" site-subsite are used in that booking update process.
  • * Null values are now returned in place of empty strings within the address elements included with car and hotel components.
  • * A `vehicleDetails` array is now included when there is a car component.
  • * Rates (quoted and localized) have been added for any car component.
  • Note: In this release the `localizedPrice` is using the same currency and value as `quotedPrice`. This will be corrected in an upcoming release.
  • Custom Fields (supplementaryDataGroups). The `GET /carts` response has been enhanced to set the `defaultAnswer` for a custom field to the value from a User Profile field, when a custom field is created as both a Profile custom field (assigned to user profile page) as well as an Itinerary custom field (assigned to the itinerary review page) - using the same field name.
  • Two new elements named `newAnswer` and `newAnswerId` have been added to the `GET /carts` response. These fields are the first step in a multi-release plan to "swap" the contents in the `answer` and `answerId` elements used with custom fields. Currently `answer` holds the "code" or value associated with a selection choice, while `answerId` has the "label" or text that is shown to the traveler to guide them in making a selection. This is backwards from their intended use.
  • * In this release the new fields hold the reverse contents as in the original fields. So the contents of `newAnswerId`=`answer` and `newAnswer`=`answerId`. Clients of the `GET /carts` endpoint need to revise their application so `newAnswer` and `newAnswerId` are used in place of `answer` and `answerId`, but with reverse mapping.
  • * In a future release the contents in `answer` and `answerId` will be swapped. At that time clients can stop using `newAnswer` and `newAnswerId`, and return to using `answer` and `answerId` - but in the “correct” manner, where `answer` is "label" shown to the traveler and `answerId` is the "code" or value for the selection.
  • * Eventually `newAnswer` and `newAnswerId` will be removed from `GET /carts`.
  • Shop by time. Several changes have been made in support of `shopByTime` during the `GET /carts` and `POST /bookings` steps: * A validation has been added so journeys of the same type - those with the same origin-destination - cannot be combined in the cart. This means two outbound journeys cannot be priced together, nor can two inbound journeys . If this is attempted the API will return an `INVALID_SELECTION_OF_JOURNEYS` error.
  • * Validation of the `combinabilityKey` between journeys is now done during `GET /carts` processing.
  • * An issue has been fixed that prevented `GET /carts` repricing for a round-trip on Air Connect carriers.
  • * The validation on `**GET **/carts` has been updated to restrict the maximum number of allowed journeys based on the type of search - only one with `oneWay` and up to two with `roundTrip`.
  • * Work was completed to allow Air Connect carriers to be mixed in same `POST /bookings` request. This applies to flights from the same aggregator - Travelfusion or Agentware - but not between aggregators.
  • Other updates have been made to improve various Corporate Travel Services: * An inconsistency during `GET /carts` with branded fares has been corrected where a flight was repriced with the lowest available fare brand, even though a different (higher) fare brand was added to the cart. Now the chosen fare brand is correctly re-priced in the cart.
  • * Handling of error 917 with "itinerary expired" has been added in `POST /bookings` to return an "unable to price" error. Previously this error handling was only done in `GET /carts` repricing.
  • * The calculation of `durationInMinutes` has been fixed when an itinerary has a time more than 24 hours.
  • * The currency codes and amounts for `quotedPrice` on Travelfusion carriers (Air Connect) have been corrected in `GET /carts` and `GET /bookings`.
  • * An issue with `GET /catalogs` has been addressed where invalid characters inside `operatingAirlineName` caused an Error 500. Now the catalog information is returned without the invalid characters.
  • * Error handling has been improved with `POST /bookings` when `isBillingAddressInProfile` is false and invalid values for `billingAddress` are included in the booking request (e.g., empty field, bad credit card number, incorrect CVV).

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.11
Target Audience
TN
Environment
Production

What's New

  • Several customer-requested enhancements are included in this release: * The `GET /travelers` API now supports the new "API Subsite Redirect" feature just added to GetThere. This configuration option - setup in GetThere Site Administration - allows travelers coming in via the Corporate Travel Services to be "redirected" to an alternate subsite, rather than the subsite they normally connect to when logging into the GetThere OBT.
  • * The `POST /catalogs` request now supports the ability to search by arrival time instead of departure time. To allow this a few new optional parameters have been added to the API. When shopping for one-way flights the new parameter `dateTimeType` is available. For round-trip shopping there are `departDateTimeType` and `returnDateTimeType`. These new parameters can be set to either `TAKEOFF` (search by departure time) or `LANDING` (search by arrival time). If these optional parameters are not included the shop is treated as `TAKEOFF`.
  • * Information about fare type options has been added into the `GET /sites` response. This data identifies which fare types are configured for use on the site-subsite - such as lowest available, no advance purchase, no penalty, or unrestricted. The response includes an array of `shoppableFareTypes` within `airConfiguration`. Each grouping within `shoppableFareTypes` describes a `fareType`, the `label` configured for that `fareType`, and an `isDefault` boolean indicator to identify which `fareType` is to be used as the default.
  • Some enhancements and updates have been made to the `GET /bookings` response: * A `siteId` element has been added. This element identifies the site and subsite which "owns" the booking. This information will be needed in the future once bookings can be modified through the Corporate Travel Services. This data will be used to ensure the configuration parameters and messages from the "owning" site-subsite are used in that booking update process.
  • * Null values are now returned in place of empty strings within the address elements included with car and hotel components.
  • * A `vehicleDetails` array is now included when there is a car component.
  • * Rates (quoted and localized) have been added for any car component.
  • Note: In this release the `localizedPrice` is using the same currency and value as `quotedPrice`. This will be corrected in an upcoming release.
  • Custom Fields (supplementaryDataGroups). The `GET /carts` response has been enhanced to set the `defaultAnswer` for a custom field to the value from a User Profile field, when a custom field is created as both a Profile custom field (assigned to user profile page) as well as an Itinerary custom field (assigned to the itinerary review page) - using the same field name.
  • Two new elements named `newAnswer` and `newAnswerId` have been added to the `GET /carts` response. These fields are the first step in a multi-release plan to "swap" the contents in the `answer` and `answerId` elements used with custom fields. Currently `answer` holds the "code" or value associated with a selection choice, while `answerId` has the "label" or text that is shown to the traveler to guide them in making a selection. This is backwards from their intended use.
  • * In this release the new fields hold the reverse contents as in the original fields. So the contents of `newAnswerId`=`answer` and `newAnswer`=`answerId`. Clients of the `GET /carts` endpoint need to revise their application so `newAnswer` and `newAnswerId` are used in place of `answer` and `answerId`, but with reverse mapping.
  • * In a future release the contents in `answer` and `answerId` will be swapped. At that time clients can stop using `newAnswer` and `newAnswerId`, and return to using `answer` and `answerId` - but in the “correct” manner, where `answer` is "label" shown to the traveler and `answerId` is the "code" or value for the selection.
  • * Eventually `newAnswer` and `newAnswerId` will be removed from `GET /carts`.
  • Shop by time. Several changes have been made in support of `shopByTime` during the `GET /carts` and `POST /bookings` steps: * A validation has been added so journeys of the same type - those with the same origin-destination - cannot be combined in the cart. This means two outbound journeys cannot be priced together, nor can two inbound journeys . If this is attempted the API will return an `INVALID_SELECTION_OF_JOURNEYS` error.
  • * Validation of the `combinabilityKey` between journeys is now done during `GET /carts` processing.
  • * An issue has been fixed that prevented `GET /carts` repricing for a round-trip on Air Connect carriers.
  • * The validation on `**GET **/carts` has been updated to restrict the maximum number of allowed journeys based on the type of search - only one with `oneWay` and up to two with `roundTrip`.
  • * Work was completed to allow Air Connect carriers to be mixed in same `POST /bookings` request. This applies to flights from the same aggregator - Travelfusion or Agentware - but not between aggregators.
  • Other updates have been made to improve various Corporate Travel Services: * An inconsistency during `GET /carts` with branded fares has been corrected where a flight was repriced with the lowest available fare brand, even though a different (higher) fare brand was added to the cart. Now the chosen fare brand is correctly re-priced in the cart.
  • * Handling of error 917 with "itinerary expired" has been added in `POST /bookings` to return an "unable to price" error. Previously this error handling was only done in `GET /carts` repricing.
  • * The calculation of `durationInMinutes` has been fixed when an itinerary has a time more than 24 hours.
  • * The currency codes and amounts for `quotedPrice` on Travelfusion carriers (Air Connect) have been corrected in `GET /carts` and `GET /bookings`.
  • * An issue with `GET /catalogs` has been addressed where invalid characters inside `operatingAirlineName` caused an Error 500. Now the catalog information is returned without the invalid characters.
  • * Error handling has been improved with `POST /bookings` when `isBillingAddressInProfile` is false and invalid values for `billingAddress` are included in the booking request (e.g., empty field, bad credit card number, incorrect CVV).

Relase note ID: 13951


  • The 18.10-01 update to the Corporate Travel Services extends the capabilities of the APIs in the areas of shopping, site information, and booking details; adds enhancements to other areas such as custom fields and error handling; and also includes a few bug fixes.
  • Shopping and Site Information. This release adds information to several APIs to help clients create a more cohesive shopping experience, particularly when Air Connect is enabled. These updates provide details about the contents of the shopping **catalog**, the payment options in the shopping cart, and the configuration of the traveler's site:
  • * The `GET /catalogs` response now includes a `supplierName` element in the itinerary to identify the data source of each flight option. (This information is included with priced itineraries, so all those returned when using `shopByPrice` and for each priced journey with `shopByTime`.) This element is set to the specific GDS providing the flight information (e.g., "SABRE") or to the individual aggregator supplying a Air Connect flight option (e.g., "AGENTWARE" or "TRAVELFUSION").
  • * In the `GET /carts` response a new `mayBeOverridden` boolean element (under `acceptableKnownPaymentOptions`) identifies situations where an override table of payment options has been configured for the site. This indicates the selected form of payment may be changed during the booking process, when PNR Editor Strings are evaluated.
  • * The `suppliers` information in the `GET /sites` response has been revised to add more information about the configuration of content data sources. Each configured source is listed by `supplierName`. GDS suppliers also include the `pcc` for that data source and an `isPrimaryGDS` boolean indicator to identify the main GDS for the site.
  • Note: Although the element name in the `GET /sites` response is `pcc`, this value refers to pseudo city code, subscriber id, or office id - whichever is appropriate for that GDS.
  • Booking Details. A few enhancements have been made to the response of `GET /bookings`:
  • * The `GET /bookings` endpoint now returns data about any car component within the booking - including `confirmationId`, `vendorCode`, `vendorName`; along with the date, time, location code, location name, location address, and location contact info for both pickUp and dropOff. See the [API Reference on GET /bookings](http://corporatetravel.developer.sabre.com/v1.0/reference#readbooking-1) for more details.
  • * Improvements have been made to the hotel information returned by `GET /bookings` to address a couple of cosmetic issues noted in the [18.10 Release Notes](http://corporatetravel.developer.sabre.com/blog/1810-release-notes#section-booking-details). This includes changing the `hotelChainCode` from lowercase to uppercase and switching room rate description (`rateDescription`) from uppercase to mixed case.
  • Error Handling. Better error information is returned in these scenarios:
  • * The `GET /bookings` API will return a response now even when the booking information does not include cost amounts. Previously this situation caused a null pointer exception and error in the API.
  • * When using `shopByTime` an empty catalog is returned when shopping is unable to find any journeys that match the criteria. Previously an error 500 was returned by `POST /catalogs`.
  • * When the flight departure time is too close to the current time (based on the site configuration) a new error with `type` = "DEPARTURE_TIME_TOO_CLOSE" is returned under the `category` of "POLICY_VIOLATION".
  • General Improvements. Other updates have been made to improve various Corporate Travel Services:
  • * Custom fields (CFEs) with a type of "select multiple" are now supported within `supplementaryDataQuestions` in `GET /carts` and also in the `POST /bookings` request. See the API References on [GET /carts](http://corporatetravel.developer.sabre.com/v1.0/reference#readcart-1) and [POST /bookings](http://corporatetravel.developer.sabre.com/v1.0/reference#createbooking-1) for more information.
  • * An issue has been fixed where the `quotedPrice` of an Air Connect booking was 10 times less than expected, in the `GET /bookings` details.
  • * In the `GET /catalogs` response, when there is a zero (`0`) `amount` for `baseFare` and `totalTaxes` those entries are now removed. In those situations the `quotedPrice` and `localizedPrice` simply have one `amount`, under `totalFare`.
  • * The timeout value for a `POST /bookings` request has been lowered to 110 seconds.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.10.01
Target Audience
TN
Environment
Production

What's New

  • The 18.10-01 update to the Corporate Travel Services extends the capabilities of the APIs in the areas of shopping, site information, and booking details; adds enhancements to other areas such as custom fields and error handling; and also includes a few bug fixes.
  • Shopping and Site Information. This release adds information to several APIs to help clients create a more cohesive shopping experience, particularly when Air Connect is enabled. These updates provide details about the contents of the shopping **catalog**, the payment options in the shopping cart, and the configuration of the traveler's site:
  • * The `GET /catalogs` response now includes a `supplierName` element in the itinerary to identify the data source of each flight option. (This information is included with priced itineraries, so all those returned when using `shopByPrice` and for each priced journey with `shopByTime`.) This element is set to the specific GDS providing the flight information (e.g., "SABRE") or to the individual aggregator supplying a Air Connect flight option (e.g., "AGENTWARE" or "TRAVELFUSION").
  • * In the `GET /carts` response a new `mayBeOverridden` boolean element (under `acceptableKnownPaymentOptions`) identifies situations where an override table of payment options has been configured for the site. This indicates the selected form of payment may be changed during the booking process, when PNR Editor Strings are evaluated.
  • * The `suppliers` information in the `GET /sites` response has been revised to add more information about the configuration of content data sources. Each configured source is listed by `supplierName`. GDS suppliers also include the `pcc` for that data source and an `isPrimaryGDS` boolean indicator to identify the main GDS for the site.
  • Note: Although the element name in the `GET /sites` response is `pcc`, this value refers to pseudo city code, subscriber id, or office id - whichever is appropriate for that GDS.
  • Booking Details. A few enhancements have been made to the response of `GET /bookings`:
  • * The `GET /bookings` endpoint now returns data about any car component within the booking - including `confirmationId`, `vendorCode`, `vendorName`; along with the date, time, location code, location name, location address, and location contact info for both pickUp and dropOff. See the [API Reference on GET /bookings](http://corporatetravel.developer.sabre.com/v1.0/reference#readbooking-1) for more details.
  • * Improvements have been made to the hotel information returned by `GET /bookings` to address a couple of cosmetic issues noted in the [18.10 Release Notes](http://corporatetravel.developer.sabre.com/blog/1810-release-notes#section-booking-details). This includes changing the `hotelChainCode` from lowercase to uppercase and switching room rate description (`rateDescription`) from uppercase to mixed case.
  • Error Handling. Better error information is returned in these scenarios:
  • * The `GET /bookings` API will return a response now even when the booking information does not include cost amounts. Previously this situation caused a null pointer exception and error in the API.
  • * When using `shopByTime` an empty catalog is returned when shopping is unable to find any journeys that match the criteria. Previously an error 500 was returned by `POST /catalogs`.
  • * When the flight departure time is too close to the current time (based on the site configuration) a new error with `type` = "DEPARTURE_TIME_TOO_CLOSE" is returned under the `category` of "POLICY_VIOLATION".
  • General Improvements. Other updates have been made to improve various Corporate Travel Services:
  • * Custom fields (CFEs) with a type of "select multiple" are now supported within `supplementaryDataQuestions` in `GET /carts` and also in the `POST /bookings` request. See the API References on [GET /carts](http://corporatetravel.developer.sabre.com/v1.0/reference#readcart-1) and [POST /bookings](http://corporatetravel.developer.sabre.com/v1.0/reference#createbooking-1) for more information.
  • * An issue has been fixed where the `quotedPrice` of an Air Connect booking was 10 times less than expected, in the `GET /bookings` details.
  • * In the `GET /catalogs` response, when there is a zero (`0`) `amount` for `baseFare` and `totalTaxes` those entries are now removed. In those situations the `quotedPrice` and `localizedPrice` simply have one `amount`, under `totalFare`.
  • * The timeout value for a `POST /bookings` request has been lowered to 110 seconds.

Relase note ID: 13952


  • The 18.10 update to the Corporate Travel Services adds support for Sabre's Branded Fares and provides a preview of the *shop by time* option used with `POST /catalogs` - complementing the already available *shop by price* option. The release also introduces a new endpoint that retrieves a list of bookings for a traveler. Plus several smaller updates and bug fixes are also included.
  • Sabre Branded Fares. Branded Fares provide a way for airlines to package their products in new and unique ways to extract greater value from their offerings, while providing options to travelers seeking different combinations of features and benefits rather than just looking for the lowest fare. These bundled fares have easy-to-remember brand names (e.g., "Dream Fare") compared to cryptic fare basis codes (e.g., KHAP6M). And they can include a wide variety of ancillary services for such things as additional air miles, lounge access, limousine services, increased baggage allowances, premium seat selection - or just about anything that will entice a traveler to choose that brand.
  • This release adds support to Corporate Travel Services for Branded Fares from Sabre. Branded Fares from other GDS's will added in future releases. These branded flight options appear in the `GET /catalogs` response as a hybrid of traditional GDS flights and the webfares available from Air Connect carriers - with normal fare rules like GDS fares (`fareRulesId`), but also with brand names (`fareBrandName`) and brand attributes (`fareBrandId`).
  • One key difference with Branded Fares is that additional brand options will be included in the `GET /catalogs` response, beyond those based on the fare restrictions (`fareType`) or cabin class (`classOfService`) from the `POST /catalogs` request. Specifically, brand options equal to or above the requested criteria will be included, when available.
  • The other difference is that when Branded Fares is enabled this automatically adds support for "combinable one-way fares". This is the ability to combine any (GDS) flights in a booking - even when the airlines are traditionally not combinable (i.e., the airlines do not share a ticketing agreement). This capability is only available when using the new *shop by time* search option (see below), since this path allows the independent selection of the outbound and return flight options.
  • Note: Branded Fares functionality depends on carrier participation and typically applies to specific markets. To take advantage of Sabre Branded Fares this feature needs to be enabled in Site Administration and support is needed within the mid/back-office systems used to process and fulfill the booking. Additional support in these systems may also be needed to handle combinable one-way fares.
  • Shop By Time. The ability to search for flights using `shopByTime` has been added to `POST /catalogs`, offering an alternative to `shopByPrice`. This method of shopping focuses on the departure time and availability of flights, rather than on the price.
  • The biggest difference between the two options is seen with round-trip shopping where `shopByTime` returns a collection of one-way `journeys` in the Catalog rather than a set of round-trip `itineraries`. These `journeys` identify outbound flight options as well as return flight options, depending on the `context` value of that journey. The client should let the traveler pick a journey from each group, using a new `combinabilityKey` to ensure the chosen flights can be priced together within the same trip. The selected options can then be added to `PATCH /carts` using `itemType` of `FLIGHT_JOURNEY` (rather than `FLIGHT_ITINERARY`).
  • Another key difference is the introduction of alternate flight itineraries in the `GET /carts` response. This list of round-trip itineraries can be found within an `alternativeFlightItineraries` collection under `bookableFlightItineraries` and represents other flight options that are available at the same price or at a lower price than the itinerary selected by the traveler.
  • Note: For more information please review the [Shop By Time Guide](http://corporatetravel.developer.sabre.com/v1.0/docs/search-by-time-guide).
  • Warning! This release is described as a **preview** of *shop by time* because some technical issues are being researched and resolved. One issue is with the time window used for shopping. Currently the `shopByTime` option ignores the `hoursTolerance` parameter in `POST /catalogs`. In addition, Air Connect flights are not always priced in the `GET /carts` process. Both of these problems will be addressed in an upcoming release.
  • Trips By Traveler. A new `GET /travelers/bookings` endpoint returns a list of all the trips booked by or for a given traveler. These include bookings made in the *GetThere* online booking tool, offline bookings acquired by the traveler in *GetThere*, or bookings made through a client application using Corporate Travel Services. The endpoint provides the following details for each booking:
  • * `bookingState` - Indicates whether the trip is `ACTIVE`, on `HOLD`, `CANCELED`, or occurred in the `PAST`
  • * `bookingId` - the unique id of the booking which can be used to retrieve trip details with `GET /bookings`
  • * `isTicketed` - boolean that is `true` when an air booking has been ticketed
  • * `isAwaitingProcessing` - boolean that is `true` when an air booking is waiting to be ticketed
  • * `confirmationId` - the booking's primary identifier within the supplier's system
  • * `components` - an array that identifies the components in the booking: `FLIGHT`, `HOTEL`, `CAR`, and/or `TRAIN`
  • * `startDate` - trip start date in YYYY-MM-DD format
  • * `endDate` - trip end date in YYYY-MM-DD format
  • * `destinationName` - name of the trip destination or location
  • Booking Details. Along with the new `GET /travelers/bookings` endpoint several enhancements have been made to the response of `GET /bookings` with information about a booking:
  • * The `GET /bookings` endpoint now returns data about any hotel component within the booking - including `hotelName`, `hotelChainCode`, the hotel system's `confirmationId`, `hotelLocationName`, `checkInDate`, `checkOutDate`, `rateDescription`, and much more. See the [API Reference on GET /bookings](http://corporatetravel.developer.sabre.com/v1.0/reference#readbooking-1) for further details.
  • * The values of `bookingState` in GET /bookings have been revised to align with those in the new `GET /travelers/bookings` endpoint and to provide more detailed information about the status of a booking. This includes the introduction of two new boolean indicators that convey status for active bookings:
  • Note: The hotel information in `GET /bookings` is being refined to address a couple of cosmetic issues. Both of these will be updated in our next release: * `hotelChainCode` is returned in lowercase format and will be changed to uppercase * Room rates are returned in uppercase format and will be changed to mixed case
  • Improved Error Handling. Better error information is returned in these scenarios:
  • * Requests to `POST /catalogs` with an invalid airport code now have a specific error response with `type` set to `INVALID_AIRPORT_CODE` and `description` containing `The provided airportCode contains an invalid value`.
  • * When a generic error is encountered an `INTERNAL_SERVER` error message is returned, rather than a general error from Sabre systems.
  • * If an operation is partially successful (so also partially unsuccessful) it is indicated with status code 207.
  • General Improvements. Other updates have been made to improve various Corporate Travel Services:
  • * The response in `GET /catalogs` for has been updated to show the `quotedPrice` and `localizedPrice` in different currencies, when appropriate. This matches the response already provided in `GET /carts`.
  • * A `type` value has been added to each defined form of payment in the `GET /carts` response - either `TRAVELER_PAYMENT_CARD` or `SITE_PAYMENT_CARD`.
  • * Temporary charge cards are now only allowed with Air Connect flights when profile cards are configured in Site Administration as an allowable form of payment for flights. In other words, temporary cards are not allowed for Air Connect flights if the site is setup to only allow flights to be booked with "central billing cards" (i.e., Site cards or BTA cards).
  • * `GET /bookings` now returns the correct `cabinTypeName` for flights with a seat assignment.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.10
Target Audience
TN
Environment
Production

What's New

  • The 18.10 update to the Corporate Travel Services adds support for Sabre's Branded Fares and provides a preview of the *shop by time* option used with `POST /catalogs` - complementing the already available *shop by price* option. The release also introduces a new endpoint that retrieves a list of bookings for a traveler. Plus several smaller updates and bug fixes are also included.
  • Sabre Branded Fares. Branded Fares provide a way for airlines to package their products in new and unique ways to extract greater value from their offerings, while providing options to travelers seeking different combinations of features and benefits rather than just looking for the lowest fare. These bundled fares have easy-to-remember brand names (e.g., "Dream Fare") compared to cryptic fare basis codes (e.g., KHAP6M). And they can include a wide variety of ancillary services for such things as additional air miles, lounge access, limousine services, increased baggage allowances, premium seat selection - or just about anything that will entice a traveler to choose that brand.
  • This release adds support to Corporate Travel Services for Branded Fares from Sabre. Branded Fares from other GDS's will added in future releases. These branded flight options appear in the `GET /catalogs` response as a hybrid of traditional GDS flights and the webfares available from Air Connect carriers - with normal fare rules like GDS fares (`fareRulesId`), but also with brand names (`fareBrandName`) and brand attributes (`fareBrandId`).
  • One key difference with Branded Fares is that additional brand options will be included in the `GET /catalogs` response, beyond those based on the fare restrictions (`fareType`) or cabin class (`classOfService`) from the `POST /catalogs` request. Specifically, brand options equal to or above the requested criteria will be included, when available.
  • The other difference is that when Branded Fares is enabled this automatically adds support for "combinable one-way fares". This is the ability to combine any (GDS) flights in a booking - even when the airlines are traditionally not combinable (i.e., the airlines do not share a ticketing agreement). This capability is only available when using the new *shop by time* search option (see below), since this path allows the independent selection of the outbound and return flight options.
  • Note: Branded Fares functionality depends on carrier participation and typically applies to specific markets. To take advantage of Sabre Branded Fares this feature needs to be enabled in Site Administration and support is needed within the mid/back-office systems used to process and fulfill the booking. Additional support in these systems may also be needed to handle combinable one-way fares.
  • Shop By Time. The ability to search for flights using `shopByTime` has been added to `POST /catalogs`, offering an alternative to `shopByPrice`. This method of shopping focuses on the departure time and availability of flights, rather than on the price.
  • The biggest difference between the two options is seen with round-trip shopping where `shopByTime` returns a collection of one-way `journeys` in the Catalog rather than a set of round-trip `itineraries`. These `journeys` identify outbound flight options as well as return flight options, depending on the `context` value of that journey. The client should let the traveler pick a journey from each group, using a new `combinabilityKey` to ensure the chosen flights can be priced together within the same trip. The selected options can then be added to `PATCH /carts` using `itemType` of `FLIGHT_JOURNEY` (rather than `FLIGHT_ITINERARY`).
  • Another key difference is the introduction of alternate flight itineraries in the `GET /carts` response. This list of round-trip itineraries can be found within an `alternativeFlightItineraries` collection under `bookableFlightItineraries` and represents other flight options that are available at the same price or at a lower price than the itinerary selected by the traveler.
  • Note: For more information please review the [Shop By Time Guide](http://corporatetravel.developer.sabre.com/v1.0/docs/search-by-time-guide).
  • Warning! This release is described as a **preview** of *shop by time* because some technical issues are being researched and resolved. One issue is with the time window used for shopping. Currently the `shopByTime` option ignores the `hoursTolerance` parameter in `POST /catalogs`. In addition, Air Connect flights are not always priced in the `GET /carts` process. Both of these problems will be addressed in an upcoming release.
  • Trips By Traveler. A new `GET /travelers/bookings` endpoint returns a list of all the trips booked by or for a given traveler. These include bookings made in the *GetThere* online booking tool, offline bookings acquired by the traveler in *GetThere*, or bookings made through a client application using Corporate Travel Services. The endpoint provides the following details for each booking:
  • * `bookingState` - Indicates whether the trip is `ACTIVE`, on `HOLD`, `CANCELED`, or occurred in the `PAST`
  • * `bookingId` - the unique id of the booking which can be used to retrieve trip details with `GET /bookings`
  • * `isTicketed` - boolean that is `true` when an air booking has been ticketed
  • * `isAwaitingProcessing` - boolean that is `true` when an air booking is waiting to be ticketed
  • * `confirmationId` - the booking's primary identifier within the supplier's system
  • * `components` - an array that identifies the components in the booking: `FLIGHT`, `HOTEL`, `CAR`, and/or `TRAIN`
  • * `startDate` - trip start date in YYYY-MM-DD format
  • * `endDate` - trip end date in YYYY-MM-DD format
  • * `destinationName` - name of the trip destination or location
  • Booking Details. Along with the new `GET /travelers/bookings` endpoint several enhancements have been made to the response of `GET /bookings` with information about a booking:
  • * The `GET /bookings` endpoint now returns data about any hotel component within the booking - including `hotelName`, `hotelChainCode`, the hotel system's `confirmationId`, `hotelLocationName`, `checkInDate`, `checkOutDate`, `rateDescription`, and much more. See the [API Reference on GET /bookings](http://corporatetravel.developer.sabre.com/v1.0/reference#readbooking-1) for further details.
  • * The values of `bookingState` in GET /bookings have been revised to align with those in the new `GET /travelers/bookings` endpoint and to provide more detailed information about the status of a booking. This includes the introduction of two new boolean indicators that convey status for active bookings:
  • Note: The hotel information in `GET /bookings` is being refined to address a couple of cosmetic issues. Both of these will be updated in our next release: * `hotelChainCode` is returned in lowercase format and will be changed to uppercase * Room rates are returned in uppercase format and will be changed to mixed case
  • Improved Error Handling. Better error information is returned in these scenarios:
  • * Requests to `POST /catalogs` with an invalid airport code now have a specific error response with `type` set to `INVALID_AIRPORT_CODE` and `description` containing `The provided airportCode contains an invalid value`.
  • * When a generic error is encountered an `INTERNAL_SERVER` error message is returned, rather than a general error from Sabre systems.
  • * If an operation is partially successful (so also partially unsuccessful) it is indicated with status code 207.
  • General Improvements. Other updates have been made to improve various Corporate Travel Services:
  • * The response in `GET /catalogs` for has been updated to show the `quotedPrice` and `localizedPrice` in different currencies, when appropriate. This matches the response already provided in `GET /carts`.
  • * A `type` value has been added to each defined form of payment in the `GET /carts` response - either `TRAVELER_PAYMENT_CARD` or `SITE_PAYMENT_CARD`.
  • * Temporary charge cards are now only allowed with Air Connect flights when profile cards are configured in Site Administration as an allowable form of payment for flights. In other words, temporary cards are not allowed for Air Connect flights if the site is setup to only allow flights to be booked with "central billing cards" (i.e., Site cards or BTA cards).
  • * `GET /bookings` now returns the correct `cabinTypeName` for flights with a seat assignment.

Relase note ID: 13953


  • The 18.07 update to the Corporate Travel Services is focused on continued improvements to error handling along with several customer requested updates and bug fixes.
  • Revisions to the error message section of API responses (which stared with the 18.04 release) continue to be rolled out in this release, with more error scenarios now handled using the new error handling and error types. The specific new scenarios covered are listed in "Table 4. Error categories and types" within our developer documentation for Errors. Everything identified as "since 18.07" is included in this update.
  • Note: Also see [Error categories and types](http://corporatetravel.developer.sabre.com/v1.0/reference#section-error-categories-and-types) for more information.
  • Other error handling improvements include:
  • * A new `resourceId` element has been added to the error section to identify the specific item associated with an error; for example when a CFE is invalid or missing in a `POST /bookings` request. And this `resourceId` is now used to identify the specific flight segment when a flight is not available following a `GET /carts` request, as shown in this example: `"resourceId": "AF:2071:0207"`.
  • * The error handling for an invalid credit card (with Air Connect) in a `POST /bookings` request has been improved. Instead of a generic error 500 the new error response specifies `"type": "INVALID_DATA"` and `"description": " Invalid card details (Invalid card.)"`.
  • * A new error message is returned when the `user` (traveler) is not found or the `site` name is incorrect in a request: `"catagory": "BAD_CONFIGURATION"` and `"type": "INVALID_PROFILE_ON_SUPPLIER_SIDE"`.
  • * Error responses will no longer include `fieldName`, `fieldPath`, and `fieldValue` elements when all of these elements are `null`.
  • Air Connect Bookings. Several updates have been made specifically related to booking flights on an Air Connect airline:
  • * A new `isBillingAddressInProfile` boolean indicator has been added to the `paymentCards` information in the `GET /travelers` and `GET /carts` responses. This indicator identifies which profile or site payment cards do not have a billing address on file, since billing address is a requirement when booking Air Connect flights.
  • * A `billingAddress` section has been added to the `POST /bookings` request, with elements for the address components (`addressLine1`, `addressLine2`, `city`, `stateProvinceCode`, `postalCode`, and `countryCode`). This section can be used to book Air Connect flights when a billing address is not on file for the payment card chosen by the traveler.
  • * Dashes (-) can now be included in a phone number when making a `POST /bookings` request for an Air Connect flight.
  • General Improvements. Other updates improve the use and performance of various Corporate Travel Services:
  • * Now `bookableAircraftSeats` can include a `null` `seatIds` element or `[]` in the `POST /bookings` request. Such a request will be treated as having no seats rather than returned as an error.
  • * Shopping requests to Travelport GDS's (Apollo, Galileo, Worldspan) are now compressed between GetThere and Travelport. This change provides an improvement of up to 40% in response time for `POST /catalogs` requests to these GDS's.
  • * In preparation for support of Branded Fares a new `isPricedAsSumOfOneWayFares` indicator has been added to the `GET /carts` response. This is used to indicate if an itinerary was priced as a set of one-way journeys rather than priced as a round-trip itinerary.
  • * A defect has been corrected where some PNR remarks were not written when booking Branded Fares flights.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.07
Target Audience
TN
Environment
Production

What's New

  • The 18.07 update to the Corporate Travel Services is focused on continued improvements to error handling along with several customer requested updates and bug fixes.
  • Revisions to the error message section of API responses (which stared with the 18.04 release) continue to be rolled out in this release, with more error scenarios now handled using the new error handling and error types. The specific new scenarios covered are listed in "Table 4. Error categories and types" within our developer documentation for Errors. Everything identified as "since 18.07" is included in this update.
  • Note: Also see [Error categories and types](http://corporatetravel.developer.sabre.com/v1.0/reference#section-error-categories-and-types) for more information.
  • Other error handling improvements include:
  • * A new `resourceId` element has been added to the error section to identify the specific item associated with an error; for example when a CFE is invalid or missing in a `POST /bookings` request. And this `resourceId` is now used to identify the specific flight segment when a flight is not available following a `GET /carts` request, as shown in this example: `"resourceId": "AF:2071:0207"`.
  • * The error handling for an invalid credit card (with Air Connect) in a `POST /bookings` request has been improved. Instead of a generic error 500 the new error response specifies `"type": "INVALID_DATA"` and `"description": " Invalid card details (Invalid card.)"`.
  • * A new error message is returned when the `user` (traveler) is not found or the `site` name is incorrect in a request: `"catagory": "BAD_CONFIGURATION"` and `"type": "INVALID_PROFILE_ON_SUPPLIER_SIDE"`.
  • * Error responses will no longer include `fieldName`, `fieldPath`, and `fieldValue` elements when all of these elements are `null`.
  • Air Connect Bookings. Several updates have been made specifically related to booking flights on an Air Connect airline:
  • * A new `isBillingAddressInProfile` boolean indicator has been added to the `paymentCards` information in the `GET /travelers` and `GET /carts` responses. This indicator identifies which profile or site payment cards do not have a billing address on file, since billing address is a requirement when booking Air Connect flights.
  • * A `billingAddress` section has been added to the `POST /bookings` request, with elements for the address components (`addressLine1`, `addressLine2`, `city`, `stateProvinceCode`, `postalCode`, and `countryCode`). This section can be used to book Air Connect flights when a billing address is not on file for the payment card chosen by the traveler.
  • * Dashes (-) can now be included in a phone number when making a `POST /bookings` request for an Air Connect flight.
  • General Improvements. Other updates improve the use and performance of various Corporate Travel Services:
  • * Now `bookableAircraftSeats` can include a `null` `seatIds` element or `[]` in the `POST /bookings` request. Such a request will be treated as having no seats rather than returned as an error.
  • * Shopping requests to Travelport GDS's (Apollo, Galileo, Worldspan) are now compressed between GetThere and Travelport. This change provides an improvement of up to 40% in response time for `POST /catalogs` requests to these GDS's.
  • * In preparation for support of Branded Fares a new `isPricedAsSumOfOneWayFares` indicator has been added to the `GET /carts` response. This is used to indicate if an itinerary was priced as a set of one-way journeys rather than priced as a round-trip itinerary.
  • * A defect has been corrected where some PNR remarks were not written when booking Branded Fares flights.

Relase note ID: 13956


  • The 18.05.01 update fixes an problem with PNR Editor strings not writing into the PNR remarks for Air Connect bookings made with the `POST /bookings` service. There are no API changes with this release.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.05.1
Target Audience
TN
Environment
Production

What's New

  • The 18.05.01 update fixes an problem with PNR Editor strings not writing into the PNR remarks for Air Connect bookings made with the `POST /bookings` service. There are no API changes with this release.

Relase note ID: 13957


  • The 18.05 update to the Corporate Travel Services incorporates changes to logging and database access required to support GDPR initiatives, and enhances the `GET /fareRules` service. Various small improvements have also been included along with the elimination of bugs.
  • The `GET fareRules` response has been improved to retrieve fare rules in more situations, in particular when requesting fare rules for the return segment of a trip. This update is most notable when using Sabre or Amadeus, or when requesting fare rules from Travelport after using `GET carts`.
  • Other updates have been made to enhance various Corporate Travel Services:
  • * Improvements were made to the `GET /carts` process used to reprice Air Connect flights - reducing the frequency of errors and mapping the remaining errors to the proper status code and message.
  • * Fixed an issue where the `fareBrandName` on Air Connect flights was missing from the `GET /carts` response.
  • * Made an change to provide the correct error response when submitting a request to `GET/catalogs` with an incorrect `catalogId`.
  • Note: There are still some issues accessing fare rules from Travelport during shopping from `GET catalogs`, and these are being investigated.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.05
Target Audience
TN
Environment
Production

What's New

  • The 18.05 update to the Corporate Travel Services incorporates changes to logging and database access required to support GDPR initiatives, and enhances the `GET /fareRules` service. Various small improvements have also been included along with the elimination of bugs.
  • The `GET fareRules` response has been improved to retrieve fare rules in more situations, in particular when requesting fare rules for the return segment of a trip. This update is most notable when using Sabre or Amadeus, or when requesting fare rules from Travelport after using `GET carts`.
  • Other updates have been made to enhance various Corporate Travel Services:
  • * Improvements were made to the `GET /carts` process used to reprice Air Connect flights - reducing the frequency of errors and mapping the remaining errors to the proper status code and message.
  • * Fixed an issue where the `fareBrandName` on Air Connect flights was missing from the `GET /carts` response.
  • * Made an change to provide the correct error response when submitting a request to `GET/catalogs` with an incorrect `catalogId`.
  • Note: There are still some issues accessing fare rules from Travelport during shopping from `GET catalogs`, and these are being investigated.

Relase note ID: 13958


  • The 18.04 update to the Corporate Travel Services introduces a change to the way error information is organized in API responses and adds two new services used to cancel bookings made with the `POST /bookings` API.
  • Shopping performance has been improved, an issue with travel policy information in the Cart has been resolved, and 24-hour shopping is now available with Amadeus. And as always, we’ve included numerous small improvements and eliminated several bugs.
  • Improved Error Handling. A revision to the error message section of our responses is being rolled out in this release, starting with the `POST /catalogs`, `GET /catalogs`, and `GET /travelers` services:
  • * Added a new `errors` section encapsulating all error information
  • * Introduced a new `category` element to better classify the error
  • * Removed the `details` container since items within this section were reorganized
  • * Revised the content in the `type` and `description` elements to provide clearer information
  • The other services also use this new error structure in their response for most errors related to a bad request (missing required field, min/max or format constraints, etc.). And the `PATCH /carts` response uses this error structure when validating seats added to a Cart. This format change will be added to other responses for all error situations in upcoming releases.
  • Other updates include new elements added to all API responses to identify the source of an error: `fieldName`, `fieldPath`, and `fieldValue`. And the Corporate Travel Services now provide better handling of errors and more informative error responses in some specific scenarios:
  • * Validation of the itinerary and seat when booking a Cart
  • * Changed the error when attempting to book without creating a Cart from `INVALID_DATA` to `ONLY_ONE_BOOKING_PER_SESSION_ALLOWED`
  • Note: The `fieldPath` and `fieldValue` elements have been added to all services; not only those associated with catalogs and travelers.
  • Cancel A Booking. A new `PATCH /bookings` service provides the ability to cancel a booking made through the Corporate Travel Services. This new service can be invoked with a `bookingId` and body of `"removeAll": "true"` to completely cancel all components in the booking – if the booking is cancellable.
  • A new `GET /bookingRules` service provides a way to obtain cancel-related details about the booking before it is cancelled. For example, can the booking be cancelled (`isCancellable`)? Can it be voided (`isVoidable`)? Is the booking refundable (`isRefundable`) and if so, how much will be returned (`refund`)? If there is a cancel penalty how much is it (`cancellationPenalty`)? The amount of information returned by the `GET /bookingRules` service varies depending on whether or not GetThere Ticket Manager is enabled for the site, or if the booking is for Southwest Airlines via Air Connect.
  • The `GET /bookingRules` service requires a `bookingRulesId` resource identifier, which has been newly added to the `GET /bookings` response. In addition, the `GET /bookings` service has been updated to return booking information from the GetThere database when that data is no longer available in the internal temporary cache. This removes the previous constraint that `GET /bookings` could only be utilized within one hour of making the initial booking, relying on data from that cache before it expired.
  • Example responses for `GET /bookingRules` (`id` in the response refers to `bookingRulesId` in the request):
  • Note: The `bookingId` value is returned by the `POST /bookings` service and should be saved by the client. This `bookingId` will be needed to cancel a booking (and in the future to modify a booking).
  • Warning! These new services should only be used with flight bookings created using the Corporate Travel Services `POST /bookings` service. The `GET /bookings` service has not yet been updated to provide itinerary information for non-flight items, and `GET /bookingRules` does not return information for every type of non-flight item. Those updates are coming in future releases.
  • Several enhancements to existing services are also included in this release:
  • * Shopping performance using `POST /catalogs` has been improved by optimizing the way data is written to the internal temporary cache.
  • * Shopping for 24-hours is now available with Amadeus when using the `POST /catalogs` request. To return flights across a 24-hour **period **the request should include `"hoursTolerance": 12`, `"departureTime": "12:00"`, and `"returnTime": "12:00"` (or `"Time": "12:00"` when shopping one-way).
  • * Elements that are `null` have been removed from API responses. For example, the previous `GET /travelers` response `"firstName": "Vernon", "middleName": null, "lastName": "Bear"` will now return as `"firstName": "Vernon", "lastName": "Bear"`.
  • * As mentioned under [Cancel a booking](#section-cancel-a-booking) above, the `GET /bookings` service now returns booking information from the GetThere database when that data is no longer available in the internal temporary cache. This removes the previous constraint where `GET /bookings` could only be used just after making a booking, before data expired from the cache.
  • * A new `customNotes` section in the `GET /carts` response provides informational links provided by Air Connect carriers. For example, Air Asia provides links for items such as FAQs, checked baggage information, terms and conditions, and requirements for contact information with home phone and Mobile Rules.
  • * Active Residual Travel Fund (RTF) vouchers on Southwest Airlines have been added to the `GET /travelers` response. When available, details such as `voucherCode`, `expirationDate`, and `initialValue`are included for each voucher in a `vouchers` section. A future update will allow these vouchers to be used as a payment option in the `POST /bookings` request. This will only be supported when Southwest Airlines is booked via Air Connect, not when booked through the GDS.
  • Other updates improve the use of specific Corporate Travel Services:
  • `GET /carts` Policy violations are now specified for all items in the Cart.
  • `GET /carts` Now only those payment options allowed by the Air Connect carriers in the itinerary are listed in `acceptableNewPaymentCards`.
  • `GET /carts` Fixed a issue with “reprice” where a price was not returned for some Air Connect carriers.
  • `GET /carts` Corrected a problem where a second request on some Air Connect carriers resulted in an error. Now requests can be submitted any number of times.
  • `GET /carts` The unused `onTimePercentage` element has been removed.
  • `POST /bookings` Frequent flyer numbers used with Air Connect airlines now get passed correctly into the booking.
  • `POST /bookings` Made sure a non-selectable seat cannot be booked.
  • `POST /bookings` Made sure a paid seat cannot be booked without a payment option.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.04
Target Audience
TN
Environment
Production

What's New

  • The 18.04 update to the Corporate Travel Services introduces a change to the way error information is organized in API responses and adds two new services used to cancel bookings made with the `POST /bookings` API.
  • Shopping performance has been improved, an issue with travel policy information in the Cart has been resolved, and 24-hour shopping is now available with Amadeus. And as always, we’ve included numerous small improvements and eliminated several bugs.
  • Improved Error Handling. A revision to the error message section of our responses is being rolled out in this release, starting with the `POST /catalogs`, `GET /catalogs`, and `GET /travelers` services:
  • * Added a new `errors` section encapsulating all error information
  • * Introduced a new `category` element to better classify the error
  • * Removed the `details` container since items within this section were reorganized
  • * Revised the content in the `type` and `description` elements to provide clearer information
  • The other services also use this new error structure in their response for most errors related to a bad request (missing required field, min/max or format constraints, etc.). And the `PATCH /carts` response uses this error structure when validating seats added to a Cart. This format change will be added to other responses for all error situations in upcoming releases.
  • Other updates include new elements added to all API responses to identify the source of an error: `fieldName`, `fieldPath`, and `fieldValue`. And the Corporate Travel Services now provide better handling of errors and more informative error responses in some specific scenarios:
  • * Validation of the itinerary and seat when booking a Cart
  • * Changed the error when attempting to book without creating a Cart from `INVALID_DATA` to `ONLY_ONE_BOOKING_PER_SESSION_ALLOWED`
  • Note: The `fieldPath` and `fieldValue` elements have been added to all services; not only those associated with catalogs and travelers.
  • Cancel A Booking. A new `PATCH /bookings` service provides the ability to cancel a booking made through the Corporate Travel Services. This new service can be invoked with a `bookingId` and body of `"removeAll": "true"` to completely cancel all components in the booking – if the booking is cancellable.
  • A new `GET /bookingRules` service provides a way to obtain cancel-related details about the booking before it is cancelled. For example, can the booking be cancelled (`isCancellable`)? Can it be voided (`isVoidable`)? Is the booking refundable (`isRefundable`) and if so, how much will be returned (`refund`)? If there is a cancel penalty how much is it (`cancellationPenalty`)? The amount of information returned by the `GET /bookingRules` service varies depending on whether or not GetThere Ticket Manager is enabled for the site, or if the booking is for Southwest Airlines via Air Connect.
  • The `GET /bookingRules` service requires a `bookingRulesId` resource identifier, which has been newly added to the `GET /bookings` response. In addition, the `GET /bookings` service has been updated to return booking information from the GetThere database when that data is no longer available in the internal temporary cache. This removes the previous constraint that `GET /bookings` could only be utilized within one hour of making the initial booking, relying on data from that cache before it expired.
  • Example responses for `GET /bookingRules` (`id` in the response refers to `bookingRulesId` in the request):
  • Note: The `bookingId` value is returned by the `POST /bookings` service and should be saved by the client. This `bookingId` will be needed to cancel a booking (and in the future to modify a booking).
  • Warning! These new services should only be used with flight bookings created using the Corporate Travel Services `POST /bookings` service. The `GET /bookings` service has not yet been updated to provide itinerary information for non-flight items, and `GET /bookingRules` does not return information for every type of non-flight item. Those updates are coming in future releases.
  • Several enhancements to existing services are also included in this release:
  • * Shopping performance using `POST /catalogs` has been improved by optimizing the way data is written to the internal temporary cache.
  • * Shopping for 24-hours is now available with Amadeus when using the `POST /catalogs` request. To return flights across a 24-hour **period **the request should include `"hoursTolerance": 12`, `"departureTime": "12:00"`, and `"returnTime": "12:00"` (or `"Time": "12:00"` when shopping one-way).
  • * Elements that are `null` have been removed from API responses. For example, the previous `GET /travelers` response `"firstName": "Vernon", "middleName": null, "lastName": "Bear"` will now return as `"firstName": "Vernon", "lastName": "Bear"`.
  • * As mentioned under [Cancel a booking](#section-cancel-a-booking) above, the `GET /bookings` service now returns booking information from the GetThere database when that data is no longer available in the internal temporary cache. This removes the previous constraint where `GET /bookings` could only be used just after making a booking, before data expired from the cache.
  • * A new `customNotes` section in the `GET /carts` response provides informational links provided by Air Connect carriers. For example, Air Asia provides links for items such as FAQs, checked baggage information, terms and conditions, and requirements for contact information with home phone and Mobile Rules.
  • * Active Residual Travel Fund (RTF) vouchers on Southwest Airlines have been added to the `GET /travelers` response. When available, details such as `voucherCode`, `expirationDate`, and `initialValue`are included for each voucher in a `vouchers` section. A future update will allow these vouchers to be used as a payment option in the `POST /bookings` request. This will only be supported when Southwest Airlines is booked via Air Connect, not when booked through the GDS.
  • Other updates improve the use of specific Corporate Travel Services:
  • `GET /carts` Policy violations are now specified for all items in the Cart.
  • `GET /carts` Now only those payment options allowed by the Air Connect carriers in the itinerary are listed in `acceptableNewPaymentCards`.
  • `GET /carts` Fixed a issue with “reprice” where a price was not returned for some Air Connect carriers.
  • `GET /carts` Corrected a problem where a second request on some Air Connect carriers resulted in an error. Now requests can be submitted any number of times.
  • `GET /carts` The unused `onTimePercentage` element has been removed.
  • `POST /bookings` Frequent flyer numbers used with Air Connect airlines now get passed correctly into the booking.
  • `POST /bookings` Made sure a non-selectable seat cannot be booked.
  • `POST /bookings` Made sure a paid seat cannot be booked without a payment option.

Relase note ID: 13961


  • The 18.01.01 update fixes an issue with some `POST /bookings` requests when using the Amadeus GDS.
  • An issue was found with some site configurations using the Amadeus GDS. Those configurations require a double "end record" (ER) entry at the end of the booking process. Prior to this update those double entries were not occurring so the booking was not completed and `POST /bookings` returned an error. This update adds the double "end record" (ER) entries when needed so bookings can complete successfully.
  • There are no API changes with this release.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.01.01
Target Audience
TN
Environment
Production

What's New

  • The 18.01.01 update fixes an issue with some `POST /bookings` requests when using the Amadeus GDS.
  • An issue was found with some site configurations using the Amadeus GDS. Those configurations require a double "end record" (ER) entry at the end of the booking process. Prior to this update those double entries were not occurring so the booking was not completed and `POST /bookings` returned an error. This update adds the double "end record" (ER) entries when needed so bookings can complete successfully.
  • There are no API changes with this release.

Relase note ID: 13962


  • The 18.01 update to the Corporate Travel APIs expands the Cart and FareRules services to provide support for all Air Connect (Budget Airline) carriers. Viewing and purchasing Air Extras is also now supported – specifically bags and meals on Travelfusion airlines and seats on GDS airlines (in conjunction with a new SeatMap service). Plus, there is a new Site Announcement service to retrieve static page messages, we've made numerous small improvements in various areas, and several bugs have been eliminated.
  • The `details` section of error responses have been updated to return the attribute related to the error, rather than the full `.json` path. In addition, the information returned in the Corporate Travel APIs now provides more informative error responses in various scenarios:
  • * Duplicate booking requests
  • * Missing `travelerId` during flight shopping
  • * Missing traveler profile during booking
  • * Flight is no longer available during booking
  • * Missing travel policy information for purpose of travel in booking request
  • * Incorrect free text information in Air Connect booking request
  • * Missing TSA information in booking request
  • * Invalid temporary card data in booking request
  • * Invalid values in shopping request
  • * Empty list due to a HTTP 500 error
  • * Invalid IATA airport code for departing or arrival airport
  • * Booking request with missing or invalid answer for `supplementaryDataQuestion`
  • Air Connect Content. All Air Connect (Budget Airline) content is now accessible through the flight Shopping service in the `GET /catalogs` response.
  • The `GET /carts` response has been expanded to provide details about payment options and other information needed to book these airlines. This includes identification of the specific credit card types allowed for payment, support for temporary payment cards (cards that are not in the traveler’s profile and are not site cards), a `paymentCardSecurityCodeRequired` boolean to identify when a CVV (Card Verification Value) is required with the credit card information, and `usageFee` data when there is an additional fee related to the type of credit card used.
  • The `GET /fareRules` response has been extended to provide brand attributes and fare rules for Air Connect flights.
  • Warning! The Cart booking service must be used to book Air Connect carriers. These flights cannot be booked directly using the `POST /bookings` request (except for Southwest Airlines – though even here use of the Cart booking service is highly recommended).
  • Shop and Book Air Extras. The `GET /carts` response now identifies which Air Extras (bags and meals) are available on Air Connect flights. Desired Air Extras can be added using `PATCH /carts` and purchased with the `POST /bookings` request.
  • Bags and meals use the same form of payment as the Air Connect flight.
  • Free seats and premium seats on GDS airlines can be shopped using the new SeatMap service, and booked using the `PATCH /carts` and `POST /bookings` requests (more information about the [SeatMap service](#section-seatmap-service) is provided below).
  • Information regarding any reserved Air Extras is included in the `GET /bookings` response.
  • SeatMap Service. The new SeatMap service provides information about all the seats in a cabin for most flights (except Air Connect flights). A `GET /seatMaps` request is sent using the `seatMapId` from a flight shopping `GET /catalogs` response. Seats with fees are identified for supported airlines. Selected seats can be added with a `PATCH /carts` request for subsequent inclusion in a `POST /bookings` request.
  • For sites with the Air Extra feature enabled (only available when Sabre is the GDS), information about premium seats on supported airlines is included in the `GET /seatMaps` response, using the traveler’s frequent flyer information from their traveler profile to determine eligibility and price. These premium seats can be reserved by including an allowable form of Air Extra payment in the `POST /bookings` request. Air Extra payment details are provided in the `GET /carts` response.
  • Temporary Payment Cards. Temporary payment cards are credit cards which are not predefined, as is the case with site cards or credit cards already in the traveler’s profile. These temporary payment cards need to be provided by the traveler during checkout and included in the `POST /bookings` request.
  • Temporary payment cards can be used for payment of flights and Air Extras (bags, meals, and seats) when enabled through Site Administration. When a temporary payment card is allowed, the `acceptableNewPaymentCards` array will be populated in the `GET /catalogs` response.
  • Note: Temporary payment card information is not saved to the traveler’s profile, so it must be entered for each booking.
  • Site Announcement. A new Site Announcement service retrieves static messages for a site using a `GET /sites/announcements` request and response. These messages - often referred to as "Company Announcements" - represent the header and footer messages shown on various pages during flight shopping and booking in the GetThere UI application:
  • * Low Fare Options (used for the Search by Price flight availability page)
  • * Seat Selection
  • * Checkout
  • * Reservation Complete
  • In addition, the carousel messages and footer message for the Traveler View of the Home page are included, as well as the Please Wait Message for Search by Price. All of the configured messages for each page and for each language are returned, using a label to identify the page and message location, along with a `languageCode` to denote the language for which the message is configured. The `id` used to access these announcement messages is a combination of `site` and `subsite` names. To assist with creation of this `id`, a new `siteId` element has been added to the `GET /travelers` response. This element provides the `site` and `subsite` names in a format which can be directly used in a `GET /sites/announcements` request.
  • Note: These messages replace the obsolete mobile messages in the announcements section of the `GET /travelers` response. Because of this the old announcements section has been removed from `GET /travelers`.
  • General Improvements. Other updates improve overall use of the Corporate Travel APIs:
  • * The `GET /fareRules` service now returns fare rules in more situations, such as when fare rules are not available for the full round-trip itinerary and must be retrieved by segment.
  • * Duplicate items in the `Cart` are rejected during `GET /carts`.
  • * The contents of `answer` and `answerId` have been swapped in `supplementaryDataQuestions` (with predefined answers) in the `GET /carts` response. For backwards compatibility, these fields have not been changed in the `GET /travelers` response, where they remain un-swapped.
  • * Quoted and localized fee values have been added to the `GET /carts` response.
  • * An answer to a `supplementaryDataQuestion` with `openResponse` in a `POST /bookings` request is now validated against the minimum and maximum value when the type is numeric or date.
  • * Fixed an issue when repricing Air Connect flights in the `GET /carts` process.
  • * The `POST /bookings` request now supports `paymentOptionId` from `GET /carts`.
  • * Corrected the format of `fareRulesId` in the `GET /carts` response.
  • * Taxes are calculated for Agentware flights in the `GET /catalogs` response based on the difference between total and base fare values.
  • * Fixed `localizedPrice` in the `GET /bookings` response.
  • * TSA-related boolean elements are now set correctly in the `GET /carts` response (`isGenderRequired`, `isDateOfBirthRequired`, and `isTSARedressNumberUsable`).

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.18.01
Target Audience
TN
Environment
Production

What's New

  • The 18.01 update to the Corporate Travel APIs expands the Cart and FareRules services to provide support for all Air Connect (Budget Airline) carriers. Viewing and purchasing Air Extras is also now supported – specifically bags and meals on Travelfusion airlines and seats on GDS airlines (in conjunction with a new SeatMap service). Plus, there is a new Site Announcement service to retrieve static page messages, we've made numerous small improvements in various areas, and several bugs have been eliminated.
  • The `details` section of error responses have been updated to return the attribute related to the error, rather than the full `.json` path. In addition, the information returned in the Corporate Travel APIs now provides more informative error responses in various scenarios:
  • * Duplicate booking requests
  • * Missing `travelerId` during flight shopping
  • * Missing traveler profile during booking
  • * Flight is no longer available during booking
  • * Missing travel policy information for purpose of travel in booking request
  • * Incorrect free text information in Air Connect booking request
  • * Missing TSA information in booking request
  • * Invalid temporary card data in booking request
  • * Invalid values in shopping request
  • * Empty list due to a HTTP 500 error
  • * Invalid IATA airport code for departing or arrival airport
  • * Booking request with missing or invalid answer for `supplementaryDataQuestion`
  • Air Connect Content. All Air Connect (Budget Airline) content is now accessible through the flight Shopping service in the `GET /catalogs` response.
  • The `GET /carts` response has been expanded to provide details about payment options and other information needed to book these airlines. This includes identification of the specific credit card types allowed for payment, support for temporary payment cards (cards that are not in the traveler’s profile and are not site cards), a `paymentCardSecurityCodeRequired` boolean to identify when a CVV (Card Verification Value) is required with the credit card information, and `usageFee` data when there is an additional fee related to the type of credit card used.
  • The `GET /fareRules` response has been extended to provide brand attributes and fare rules for Air Connect flights.
  • Warning! The Cart booking service must be used to book Air Connect carriers. These flights cannot be booked directly using the `POST /bookings` request (except for Southwest Airlines – though even here use of the Cart booking service is highly recommended).
  • Shop and Book Air Extras. The `GET /carts` response now identifies which Air Extras (bags and meals) are available on Air Connect flights. Desired Air Extras can be added using `PATCH /carts` and purchased with the `POST /bookings` request.
  • Bags and meals use the same form of payment as the Air Connect flight.
  • Free seats and premium seats on GDS airlines can be shopped using the new SeatMap service, and booked using the `PATCH /carts` and `POST /bookings` requests (more information about the [SeatMap service](#section-seatmap-service) is provided below).
  • Information regarding any reserved Air Extras is included in the `GET /bookings` response.
  • SeatMap Service. The new SeatMap service provides information about all the seats in a cabin for most flights (except Air Connect flights). A `GET /seatMaps` request is sent using the `seatMapId` from a flight shopping `GET /catalogs` response. Seats with fees are identified for supported airlines. Selected seats can be added with a `PATCH /carts` request for subsequent inclusion in a `POST /bookings` request.
  • For sites with the Air Extra feature enabled (only available when Sabre is the GDS), information about premium seats on supported airlines is included in the `GET /seatMaps` response, using the traveler’s frequent flyer information from their traveler profile to determine eligibility and price. These premium seats can be reserved by including an allowable form of Air Extra payment in the `POST /bookings` request. Air Extra payment details are provided in the `GET /carts` response.
  • Temporary Payment Cards. Temporary payment cards are credit cards which are not predefined, as is the case with site cards or credit cards already in the traveler’s profile. These temporary payment cards need to be provided by the traveler during checkout and included in the `POST /bookings` request.
  • Temporary payment cards can be used for payment of flights and Air Extras (bags, meals, and seats) when enabled through Site Administration. When a temporary payment card is allowed, the `acceptableNewPaymentCards` array will be populated in the `GET /catalogs` response.
  • Note: Temporary payment card information is not saved to the traveler’s profile, so it must be entered for each booking.
  • Site Announcement. A new Site Announcement service retrieves static messages for a site using a `GET /sites/announcements` request and response. These messages - often referred to as "Company Announcements" - represent the header and footer messages shown on various pages during flight shopping and booking in the GetThere UI application:
  • * Low Fare Options (used for the Search by Price flight availability page)
  • * Seat Selection
  • * Checkout
  • * Reservation Complete
  • In addition, the carousel messages and footer message for the Traveler View of the Home page are included, as well as the Please Wait Message for Search by Price. All of the configured messages for each page and for each language are returned, using a label to identify the page and message location, along with a `languageCode` to denote the language for which the message is configured. The `id` used to access these announcement messages is a combination of `site` and `subsite` names. To assist with creation of this `id`, a new `siteId` element has been added to the `GET /travelers` response. This element provides the `site` and `subsite` names in a format which can be directly used in a `GET /sites/announcements` request.
  • Note: These messages replace the obsolete mobile messages in the announcements section of the `GET /travelers` response. Because of this the old announcements section has been removed from `GET /travelers`.
  • General Improvements. Other updates improve overall use of the Corporate Travel APIs:
  • * The `GET /fareRules` service now returns fare rules in more situations, such as when fare rules are not available for the full round-trip itinerary and must be retrieved by segment.
  • * Duplicate items in the `Cart` are rejected during `GET /carts`.
  • * The contents of `answer` and `answerId` have been swapped in `supplementaryDataQuestions` (with predefined answers) in the `GET /carts` response. For backwards compatibility, these fields have not been changed in the `GET /travelers` response, where they remain un-swapped.
  • * Quoted and localized fee values have been added to the `GET /carts` response.
  • * An answer to a `supplementaryDataQuestion` with `openResponse` in a `POST /bookings` request is now validated against the minimum and maximum value when the type is numeric or date.
  • * Fixed an issue when repricing Air Connect flights in the `GET /carts` process.
  • * The `POST /bookings` request now supports `paymentOptionId` from `GET /carts`.
  • * Corrected the format of `fareRulesId` in the `GET /carts` response.
  • * Taxes are calculated for Agentware flights in the `GET /catalogs` response based on the difference between total and base fare values.
  • * Fixed `localizedPrice` in the `GET /bookings` response.
  • * TSA-related boolean elements are now set correctly in the `GET /carts` response (`isGenderRequired`, `isDateOfBirthRequired`, and `isTSARedressNumberUsable`).

Relase note ID: 13963


  • The 17.12.02 update provides a fix for a cache issue with large shopping “payloads” and restores the increase in shopping options. This means more flight options are now available from the Travelport GDS’s – as well as from Sabre Intellisell and Agentware (for Southwest Airlines).
  • The 17.12 release included an improvement to return many more options during shopping, from all sources. Unfortunately, this update had unintended consequences with an intermediary cache mechanism used to hold flight options, due to the larger “payload” size that comes with a larger shopping response. As a result, that portion of the update was disabled shortly after the 17.12 release, reducing the shopping options back to previous levels for requests to any of the Travelport GDS’s. This 17.12.02 update adds compression so the cache can support large shopping “payloads”, and also re-enables the increase in shopping options.
  • There are no API changes with this release.

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.17.12.02
Target Audience
TN
Environment
Production

What's New

  • The 17.12.02 update provides a fix for a cache issue with large shopping “payloads” and restores the increase in shopping options. This means more flight options are now available from the Travelport GDS’s – as well as from Sabre Intellisell and Agentware (for Southwest Airlines).
  • The 17.12 release included an improvement to return many more options during shopping, from all sources. Unfortunately, this update had unintended consequences with an intermediary cache mechanism used to hold flight options, due to the larger “payload” size that comes with a larger shopping response. As a result, that portion of the update was disabled shortly after the 17.12 release, reducing the shopping options back to previous levels for requests to any of the Travelport GDS’s. This 17.12.02 update adds compression so the cache can support large shopping “payloads”, and also re-enables the increase in shopping options.
  • There are no API changes with this release.

Relase note ID: 13964


  • The 17.12 update to the Corporate Travel APIs includes improved error handling, shopping for Southwest Airlines through Air Connect, introduction of new Cart and Booking features, and other general improvements.
  • The information returned in the Corporate Travel APIs provides more detailed error responses in various scenarios:
  • * Error trying to create or price the itinerary
  • * Departure time is too close to shopping time (per Site Admin settings)
  • * CFE information is invalid or missing in booking
  • * Flight price changed between shopping and booking
  • * Flight is sold out at time of booking
  • * Temporary issue reported by our supplier (GDS)
  • * User profile does not exist
  • * Booking was already completed (trying to book same item again)
  • * The requested class of service is not supported
  • * Underlying service timed out
  • Air Connect Content. It is now possible to shop for Southwest Airlines flights using Air Connect via our partner, Agentware. New elements in the `GET Catalog` response provide information about Air Connect (Budget Airline) flight options.
  • Cart Service. The first versions of the `PATCH /carts` and `GET /carts` services are now available. The `GET /carts` response includes several items that provide information to be used during checkout and booking.
  • Booking Service. The Booking services have been enhanced in several areas.
  • General Improvements. Other updates improve overall use of the `GET /catalogs` API and address system performance: * Shopping will now return many more options from all sources, including the Travelport GDS’s. * Shopping has been improved by reducing the number of database calls related to cities and airports. * A temporary fix was implemented for an issue with “Corporate Id” when using Sabre Intellisell (a permanent fix will be made in the underlying GT "core" system in a later GetThere release).

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.17.12
Target Audience
TN
Environment
Production

What's New

  • The 17.12 update to the Corporate Travel APIs includes improved error handling, shopping for Southwest Airlines through Air Connect, introduction of new Cart and Booking features, and other general improvements.
  • The information returned in the Corporate Travel APIs provides more detailed error responses in various scenarios:
  • * Error trying to create or price the itinerary
  • * Departure time is too close to shopping time (per Site Admin settings)
  • * CFE information is invalid or missing in booking
  • * Flight price changed between shopping and booking
  • * Flight is sold out at time of booking
  • * Temporary issue reported by our supplier (GDS)
  • * User profile does not exist
  • * Booking was already completed (trying to book same item again)
  • * The requested class of service is not supported
  • * Underlying service timed out
  • Air Connect Content. It is now possible to shop for Southwest Airlines flights using Air Connect via our partner, Agentware. New elements in the `GET Catalog` response provide information about Air Connect (Budget Airline) flight options.
  • Cart Service. The first versions of the `PATCH /carts` and `GET /carts` services are now available. The `GET /carts` response includes several items that provide information to be used during checkout and booking.
  • Booking Service. The Booking services have been enhanced in several areas.
  • General Improvements. Other updates improve overall use of the `GET /catalogs` API and address system performance: * Shopping will now return many more options from all sources, including the Travelport GDS’s. * Shopping has been improved by reducing the number of database calls related to cities and airports. * A temporary fix was implemented for an issue with “Corporate Id” when using Sabre Intellisell (a permanent fix will be made in the underlying GT "core" system in a later GetThere release).

Relase note ID: 13965


  • 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"

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.17.11
Target Audience
TN
Environment
Production

What's New

  • 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"

Relase note ID: 13966


  • 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`

API Information

Response Format
JSON
Method/Endpoint
*
Current Version
1.17.10
Target Audience
TN
Environment
Production

What's New

  • 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`

Relase note ID: 13967