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