Sabre APIs currently supports up to 5 versions of an API. We urge customers to frequent Sabre Dev Studio to bensure that you and your team are using the most recent version of an API.
It is equally important that you periodically plan your migration to an updated version of an API. All legacy versions for an API are now available to existing customers—this guarantees that you have access to legacy documentation as you version-up your application to the latest features and functionality. View the Product Catalog to find the most recent version of our APIs.
View the release notes site for the latest updates and enhancements.
Older API versions are periodically retired from the system with a minimum of 90 days advance notice prior to an API version being retired. View the following APIs set for retirement.
|API Name||Action Code / URI||Version||Type||CERT Test Run Date||CERT Block Date||PROD Test Run Date||PROD Block Date|
|Air Fare by City Pairs||FareLLSRQ||1.10.1 - 2.2.0||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||Deprecated (Mar 2019)||Deprecated (Mar 2019)|
|Auto Price Air Exchanges||QREXLLSRQ||1.x.x||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||Deprecated (Mar 2019)||Deprecated (Mar 2019)|
|Get Itinerary||TravelItineraryReadRQ||3.3.0||SOAP||Deprecated (Mar 2019)||Deprecated (Mar 2019)||Deprecated (May 2019)||Deprecated (May 2019)|
|Get Itinerary||OTA_TravelItineraryReadLLSRQ||1.x.x||SOAP||TBD||Deprecated (Nov 2018)||TBD||TN: July 28, 2019
AS: February 5, 2020
|Orchestrated Air Booking||Enhanced_AirBookRQ||1.x.x||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||September 4, 2019, 3am-3:30am CT||September 24, 2019|
|Orchestrated Air Booking||Enhanced_AirBookWithTaxRQ||1.x.x||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||September 4, 2019, 3am-3:30am CT||September 24, 2019|
|Passenger Details||PassengerDetailsRQ||1.x.x||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||September 4, 2019, 3am-3:30am CT||September 24, 2019|
|Extended Air Availability||ExtendedAirAvailRQ||1.x.x - 2.x.x||SOAP||July 18, 2019, 3am-4am CT||August 8, 2019||September 4, 2019, 3am-3:30am CT||September 24, 2019|
|Hotel Availability||OTA_HotelAvailLLSRQ||1.x.x-2.x.x||SOAP||TBD||September 30, 2019||TBD||September 30, 2019|
|Hotel Property Description||HotelPropertyDescriptionLLSRQ||1.x.x-2.x.x||SOAP||TBD||September 30, 2019||TBD||September 30, 2019|
|Hotel Rate Description||HotelRateDescriptionLLSRQ||1.x.x-2.x.x||SOAP||TBD||September 30, 2019||TBD||September 30, 2019|
|Book Hotel Reservation||OTA_HotelResLLSRQ||1.x.x-2.x.x||SOAP||TBD||September 30, 2019||TBD||September 30, 2019|
|Get Itinerary||TravelItineraryReadLLSRQ||1.x.x - 2.x.x||SOAP||TBD||September 29, 2019||TBD||TN: October 29, 2019
AS: Feburary 5, 2020
|Bargain Finder Max||BargainFinderMaxRQ||1.0.1 - 1.9.7||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Bargain Finder Max||/shop/flights/||1.0.1 - 1.9.7||REST||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Bargain Finder Max Shop Across Passenger Types||BargainFinderMax_SAPTRQ||1.0.1 - 1.9.7||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Bargain Finder Max Alternate Dates||BargainFinderMax_ADRQ||1.0.1 - 1.9.7||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Bargain Finder Max Alternate Dates||/shop/altdates/flights/||1.0.1 - 1.9.7||REST||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Bargain Finder Max Alternate Airport Shop||BargainFinderMax_ASRQ||1.0.1 - 1.9.7||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Bargain Finder Max Alternate Airport Shop||/shop/altairports/flights/||1.0.1 - 1.9.7||REST||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Passenger Details||PassengerDetailsRQ||2.x.x - 3.0.0||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Orchestrated Air Booking||EnhancedAirBookRQ||2.x.x - 3.0.0||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Basic Fare Shop JR||OTA_AirLowFareSearchLLSRQ||1.x.x - 2.x.x||SOAP||Deprecated (Feb 2019)||Deprecated (Feb 2019)||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Display Seat Map||IMAP_AirSeatMapLLSRQ||1.0.1 - 2.1.0||SOAP||September 19, 2019, 3am-4am CT||October 10, 2019||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Basic Fare Shop||BargainFinderPlusLLSRQ||1.x.x - 2.x.x||SOAP||September 19, 2019, 3am-4am CT||October 10, 2019||November 6, 2019, 3am-3:30am CT||December 4, 2019|
|Get Itinerary||TravelItineraryReadRQ||3.4.0 - 3.9.0||SOAP||TBD||January 6, 2020||TBD||February 5, 2020|
Note: TBD denotes To Be Determined, and CT denotes Central Time.
Sabre is in the process of discontinuing access to legacy URLs used to connect to the Sabre APIs in TSTS, CERT and PROD environments.
Even though Sabre will not block access to the legacy Sabre API endpoints at this point, past June 30, 2018 these endpoints will no longer be supported (no additional enhancements will be implemented on these endpoints).
To ensure your applications are not affected, please migrate to the new URLs listed below as soon as possible.
|Environment||Legacy URLs||Legacy IP Addresses||New URLs||New IP Addresses|
Product Lifecycle Terms
Sabre teams should use the following terms to indicate to customers the phase in the product lifecycle for a given version. For example, if an API is to be deployed in the "Alpha" or "Beta" phase, Sabre teams should use these terms in the API description.
|Phase||Release||Environment||Customer Availability||Dev Studio Visibility|
|Planned||Release dates and availability have been established and communicated to internal Sabre stakeholders. Customers have provided input on the features and enhancements that are driving the product release.||-||-||-|
|Alpha||Deployed for prototype-level customer testing and validation.||Test||Yes, available to select customers.||No, Sabre product teams are responsible for providing documentation to select customers.|
|Beta||Deployed for production-level customer validation testing (CVT)||Test and/or Production||Yes, available to select customers.||Yes, available to select customers.|
|Live||Operational and fully-supported with general availability (GA)||Test and Production||Yes, available to new and existing customers.||Yes, available to new and existing customers.|
|Legacy||Operational and fully-supported (including backward- compatible bug fixes).||Test and Production||Yes, but existing customers only.||No, not available to new or existing customers.|
|Retired||Unpublished from Test and Production.||None||No, routing has been disabled.||No, documentation has been archived.|
Major version release (breaking)
The following backward-incompatible changes constitute whether a release would be considered a major version release.
- Adding a required field to the request.
- Removing or renaming a service, interface, field, method or enum value.
- Changing the type of a field (ex: from a number to a string).
- Changing a resource name format (applicable to JSON format).
- Changing visible behavior of existing requests.
- Adding an attribute to the response (applicable to XML format).
- Changing the URL format in the HTTP definition (applicable to JSON format).
- Adding a read/write field to a resource message (applicable to JSON format).
Minor version release (non-breaking)
The following backward-compatible changes constitute whether a release would be considered a minor version release.
- Adding a method, such as GET to a POST resource (applicable to JSON format).
- Adding an optional parameter to the request.
- Adding an attribute to the response (applicable to JSON format).
- Adding a value to an enum (i.e. a parameter's valid values).
- Adding an output-only resource field (applicable to JSON format).
Patch version release (non-breaking)
The following backward-compatible changes constitute whether a release would be considered a patch version release.
- Fixing a bug (any urgent issue that cannot wait until the next release).
- A patch release should never require a schema update. What is a bug? For example, if an attribute is expected to be an airport code (e.g. DFW), and is returning "null" this would be considered a bug. Another example is if a successful response returns an error node in an XML response, this would also be considered a bug as it should be returning a success node.
- Note: if a release requires an update to the schema, this is considered a minor release. API teams may need to change how they release an API to accommodate this scheme of releasing a patch in the same version.
Live Version Scheme
XML and XML-to-JSON product version scheme
The following version scheme is used for Live Sabre XML and XML-to-JSON products:
- X.0 for Major releases. The major is an ordinal starting with 1 for the first live release (ex: v1.0). (No numeral greater than 0 thereafter.)
- X.X for Minor releases. The ordinal starts with 1 for the first release of any major release (ex: v1.1). (No numeral thereafter.)
- A patch release does not increase the ordinal and should be released in the same version (v1.1). A patch release must not include functionality updates or schema updates. (No numeral thereafter.)
Given a version number MAJOR.MINOR.PATCH, the following should be incremented:
- MAJOR version when Sabre makes backward- incompatible (breaking) API changes,
- MINOR version when Sabre adds functionality in a backwards-compatible (non-breaking) manner.
- You do not need to increment the ordinal for a PATCH release.
JSON product version scheme
The following version scheme is used for Live Sabre JSON products:
- All minor and patch changes, features, and enhancements are rolled up into the pre-existing major version. For example, if an optional parameter or a new method is added to an endpoint (a minor release), the version would remain the same. The major is an ordinal starting with v1 for the first Live release.
- If a major change is introduced that is not backward-compatible, Sabre must increment the version ordinal. For example, a breaking change for /v1/flights/reservation/ would result in an endpoint of /v1/flights/reservation/.
Upgrading customers to a new Live version
- Sending out email notifications that a new Live version will be released, and therefore, that a pre-existing version will become a Legacy version is highly recommended, but not required.
- This should occur at least 30 days prior to launch-day of the new Live version, or preferably, when the new version is deployed to the test environment - whichever occurs first.
- It is highly recommended, and may be required, that Sabre works with their marketing representative to communicate the business value of the new version.
- It may be required that Sabre works with their marketing representative on these communications based on the defined Tier of their product.
Demonstrate the business value of the new release by providing sufficient documentation. This may be in the form of:
- Detailed documentation of the new features of the Live version.
- New documentation artifacts (e.g. schema) for customers to consume the Live version.
- Release notes that detail the new features to assist customers in their decision to migrate to the Live version.
Release impact table
The following table summarizes the actions Sabre takes to provide customers with the information they need to begin using a release. Additional information may be required based on the Sabre product tier. Sabre teams should contact their marketing representative for details.
|Detailed Documentation||Release Notes||Updated Documentation Artifacts||Marketing Representative||30-Day Advance Notice|
Frequently Asked Questions
Sabre APIs supports the five most recent active versions of a Web service, or less in the case of a service with less than five active versions. This covers the current production (PROD) version minus 4 versions. When a new version of an API is introduced, the oldest version of that API [n-4] will be targeted for removal.
Sabre maintains an API Deprecation Schedule of APIs flagged for retirement. Customers are expected to update to the latest version available or to migrate to a replacement API. Using the latest API version guarantees access to the newest features and functionalities that have been introduced since the initial application was introduced.
No. The APIs flagged for retirement will be removed and the gateway will no longer accept requests. Sabre strongly recommends regularly checking Sabre Dev Studio to see which APIs have been flagged for retirement and to make plans in advance to make any required updates.
Deprecating APIs is a critical function of proper API management and is considered a good practice in the industry. Generally speaking, new APIs introduce new features, eliminate bugs and known issues, and often improve efficiency while retaining previous features and functionalities. Old versions will be decommissioned to support the current versioning policy in place, current production version minus four versions.
No. There are no costs associated with upgrading to newer APIs versions. Existing contractual charges remain the same if you are upgrading to the family of the same API.
Once a service has been removed, it is no longer available to be used in a customer's application. The customer`s application will receive an error if the application has not been updated with a supported service version. When this occurs the client application must be upgraded to use a newer version. Customers who have already updated their applications to bring their service version calls into compliance are unaffected by the removal.
Please contact your Account Director.
The list of APIs flagged for retirement will be updated on Sabre Dev Studio on a quarterly basis.
Sabre strongly recommends regularly checking Sabre Dev Studio to see which APIs have been flagged for retirement. You should then check the version of the API services you use and take appropriate steps to prepare for an update if a version you use is targeted for cancellation.
Yes. Before removing an old version, service teams are required to guarantee new APIs are backward compatible retaining previous features and functionalities; however, new schemas may have been introduced to support new features and functionalities.