Sabre APIs currently supports up to 5 versions of an API. We urge customers to frequent Sabre Dev Studio to be sure 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|
|Bargain Finder Max||BargainFinderMaxRQ||1.0.1 - 1.9.7||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Bargain Finder Max||/shop/flights/||1.0.1 - 1.9.7||REST||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Bargain Finder Max Shop Across Passenger Types||BargainFinderMax_SAPTRQ||1.0.1 - 1.9.7||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Bargain Finder Max Alternate Dates||BargainFinderMax_ADRQ||1.0.1 - 1.9.7||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Bargain Finder Max Alternate Dates||/shop/altdates/flights/||1.0.1 - 1.9.7||REST||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Bargain Finder Max Alternate Airport Shop||BargainFinderMax_ASRQ||1.0.1 - 1.9.7||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Bargain Finder Max Alternate Airport Shop||/shop/altairports/flights/||1.0.1 - 1.9.7||REST||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Air Fare by City Pairs||FareLLSRQ||1.10.1 - 2.2.0||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Orchestrated Air Booking||Enhanced_AirBookRQ||1.x.x||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Orchestrated Air Booking||Enhanced_AirBookWithTaxRQ||1.x.x||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Passenger Details||PassengerDetailsRQ||1.x.x||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Passenger Details||PassengerDetailsRQ||2.x.x - 3.0.0||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Orchestrated Air Booking||EnhancedAirBookRQ||2.x.x - 3.0.0||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Auto Price Air Exchanges||QREXLLSRQ||1.x.x||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Get Itinerary||OTA_TravelItineraryReadLLSRQ||1.x.x||SOAP||TBD||Deprecated (Nov 2018)||TBD||March 15, 2019|
|Rail RCP APIs||Rail RCP APIs||1.20.0||SOAP||TBD||TBD||TBD||January 30, 2019|
|Rail RCP APIs||Rail RCP APIs||1.21.0||SOAP||TBD||TBD||TBD||March 30, 2019|
|Basic Fare Shop JR||OTA_AirLowFareSearchLLSRQ||1.x.x - 2.x.x||SOAP||February 12, 2019, 3am-4am CT||February 28, 2019||March 12, 2019, 3am-3.30am CT||March 28, 2019|
|Get Itinerary||TravelItineraryReadLLSRQ||1.x.x - 2.x.x||SOAP||TBD||March 29, 2019||TBD||May 25, 2019|
|Get Itinerary||TravelItineraryReadRQ||3.3.0||SOAP||TBD||March 29, 2019||TBD||April 19, 2019|
|Get Itinerary||TravelItineraryReadRQ||3.4.0 - 3.9.0||SOAP||TBD||June, 2019||TBD||July, 2019|
|Display Seat Map||IMAP_AirSeatMapLLSRQ||1.0.1 - 2.1.0||SOAP||TBD||TBD||TBD||June 30, 2019|
|Basic Fare Shop||BargainFinderPlusLLSRQ||1.x.x - 2.x.x||SOAP||TBD||TBD||TBD||June 30, 2019|
|Extended Air Availability||ExtendedAirAvailRQ||1.x.x - 2.x.x||SOAP||TBD||TBD||TBD||June 30, 2019|
Note: TBD denotes To Be Determined; 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 to 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; 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.|
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)
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)
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. Or if a successful response returns an error node in an XML response, this would 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, and
- 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
- Advance email notification 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 more 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 (ex: schema) for customers to consume the Live version;
- and release notes that detail the new features to assist customers in their decision to migrate to the Live version.
Release impact matrix
The following matrix summarizes the actions Sabre takes to provide customers with the information they need to begin consuming 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 “best 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 to upgrading to newer APIs versions, existing contractual charges remains the same if you are upgrading to the same APIs family.
Once a service has been removed, it is no longer available to be consumed 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.