API Versioning

An important best practice to follow when planning your development is to make sure you are using the most recent version of an API. It is equally important that you periodically plan migration to an updated version of an API or to a replacement API. This guarantees that you have access to enhanced features and functionality that may have been introduced since your initial development. Sabre APIs currently support up to 5 versions of an API.

API Deprecation Schedule

API Name Action Code / URI Version Type Date
Air Fare by City Pairs FareLLSRQ 1.0.1 - 2.2.0 SOAP Dec 13,2017
Bargain Finder Max BargainFinderMaxRQ 1.0.1 - 1.9.7 SOAP Dec 13, 2017
Bargain Finder Max /shop/flights/ 1.0.1 - 1.9.7 REST Dec 13, 2017
Bargain Finder Max Shop Across Passenger Types BargainFinderMax_SAPTRQ 1.0.1 - 1.9.7 SOAP Dec 13, 2017
Bargain Finder Max Alternate Dates BargainFinderMax_ADRQ 1.0.1 - 1.9.7 SOAP Dec 13, 2017
Bargain Finder Max Alternate Dates /shop/altdates/flights/ 1.0.1 - 1.9.7 REST Dec 13, 2017
Bargain Finder Max Alternate Airport Shop BargainFinderMax_ADRQ 1.0.1 - 1.9.7 SOAP Dec 13, 2017
Bargain Finder Max Alternate Airport Shop /shop/altairports/flights/ 1.0.1 - 1.9.7 REST Dec 13, 2017
Create Passenger Name Record /passenger/records?mode=create 1.0.0 REST Dec 13, 2017

API Deprecation Schedule 2018

Sabre is in the process of discontinuing access to legacy URLs used to connect to the Sabre APIs in TSTS, CERT and PROD environments. The final date is pending but will correspond to the PCI TLS security mandate date (currently scheduled for June, 2018). All applications connecting to Sabre through the URLs listed in the “Legacy URLs” column will lose all access to Sabre APIs if they are not migrated to the “New URLs” listed below.

Environment Legacy URLs Legacy IP Addresses New URLs New IP Addresses
Production webservices.sabre.com 151.193.160.91 webservices.havail.sabre.com 151.193.4.55
151.193.0.56
Production webservices2.sabre.com 151.193.160.105 webservices.havail.sabre.com 151.193.4.55
151.193.0.56
Production webservices3.sabre.com 151.193.51.17 webservices.havail.sabre.com 151.193.4.55
151.193.0.56
Production webservices.lp.sabre.com 151.193.51.15 webservices.havail.sabre.com 151.193.4.55
151.193.0.56
Production webservices.as.sabre.com 151.193.51.13 webservices-as.havail.sabre.com 151.193.4.61
151.193.0.61
Production api.sabre.com 151.193.59.58 api.havail.sabre.com 151.193.4.54
151.193.0.55
Production 2sg.sabre.com 151.193.59.51 api.havail.sabre.com 151.193.4.54
151.193.0.55
Test/Certification sws-crt.cert.sabre.com 151.193.52.22 sws-crt.cert.havail.sabre.com 151.193.109.22
151.193.105.24
Test/Certification sws-sts.cert.sabre.com 151.193.52.23 sws-sts.cert.havail.sabre.com 151.193.109.30
151.193.105.33
Test/Certification sws-crt.as.cert.sabre.com 151.193.52.48 sws-crt-as.cert.havail.sabre.com 151.193.109.25
151.193.105.27
Test/Certification api.test.sabre.com 151.193.52.94 api-crt.cert.havail.sabre.com 151.193.109.23
151.193.105.25

Guidelines for Upgrading Client Applications:

The major level portion of the API version number is incremented, i.e. 2.0.0

If clients want to take advantage of a platform upgrade, or a major enhancement/re-write, they must upgrade their application to consume the upgraded, major level version. Please note that these types of changes are not deemed backwards compatible between major versions, i.e. API version 2.0.0 is not backwards compatible with API version 1.0.0.

The minor level portion of the API version number is incremented, i.e. 2.1.0

If clients want to take advantage of a minor enhancement, i.e. new request or response elements/attributes, or a bug fix that resulted in a schema change, i.e. new request or response structures, or where the data type associated with an existing element or attribute is changed, they must upgrade their application to consume the upgraded, minor level version. Please note that these types of changes are not deemed backwards compatible between minor versions, i.e. API version 2.1.0 is not backwards compatible with API version2.0.0.

The patch level portion of the API version number is incremented, i.e. 2.0.1

If clients want to take advantage of a bug fix that contained in a new API version that did not result in a schema change, they must upgrade their application to consume the upgraded, patch level version. This upgrade simply consists of incrementing the patch level digit, and retesting. These types of changes are deemed backwards compatible with the current minor version, i.e. API version 2.0.1 is backwards compatible with API version 2.0.0.

The client must upgrade their application to consume a newer version.


REST API Versioning

Each of our REST APIs is versioned. When any of these APIs are called, an application must include the API version in the request URI, in the form of vn, where n represents the version number.

Example

https://api.sabre.com/v1/shop/flights/fares?origin=ATL&destination=LAS&lengthofstay=3

Version compatibility

  • Changes to existing API versions: an existing API version will receive fixes and minor changes that expose new behavior when the changes are backward compatible and do not impact clients negatively.
  • New API versions: a new API version will be added when new functionality and major changes are not backward compatible.
  • Multiple concurrent versions: Sabre will maintain multiple concurrent versions of an API. Before a version becomes obsolete, Sabre will provide adequate notification, including on the applicable API documentation page, before removing the version from service.

SOAP API Versioning

Individual, SOAP-based Sabre APIs are versioned to distinguish changes that are made from API from one release to another. The first version of an API includes basic content, and upgraded versions include enhancements to existing content, new content, as well as corrections, i.e. bug fixes.

A new version of an API is created whenever any of the following occurs:

  • Changes are made to an API that causes the request or response structure of the API to change, i.e. an enhancement.
  • Changes are made to an API to correct an issue, i.e. a bug fix.

Older API versions are periodically removed from the system. Customers are a provided with a minimum of 90 days advance notification prior to a particular API version being removed or otherwise being disabled. When APIs are upgraded, their corresponding WSDL and schema documents are also versioned in the same manner. Clients should check the release notes, which are available on Sabre Dev Studio, to ensure that they are aware of any changes/updates being made.

The first release of an API is assigned an initial version number. Whenever changes are made to an API, the first, second, or third numeral is incremented depending upon the nature of the change.

If the change causes a major request or response change, i.e. an API rewrite, or an entire platform upgrade, the first numeral, i.e. the major version level, is incremented. These types of changes are not deemed backwards compatible with previous API versions, i.e. API version 2.0.0 is not backwards compatible with API version 1.0.0. In these instances application developers will need to increment the major level digit, incorporate the functionality contained in the new major version into their application, and retest.

If the change causes a structural request or response change, i.e. an enhancement or a bug fix resulting in a schema change, the second numeral, the minor version level, is incremented, i.e. 2.1.0. These types of changes are not deemed backwards compatible with previous API versions, i.e. API version 2.1.0 is not backwards compatible with API version 2.0.0, or API version 2.0.1. In these instances application developers will need to increment the minor level digit, add the new functionality contained in the SOAP-Based Sabre APIs Versioning Strategy, v1.3 Sabre Confidential Page 2 of 3 new minor version into their application, and retest.

If the change is to simply resolve a minor issue, i.e. a bug fix that doesn’t require any sort of schema change, the third numeral, the patch version level, is incremented, i.e. 2.0.1. These types of changes do not require schema updates so they are deemed backwards compatible between API versions sharing the same minor patch level, i.e. API version 2.0.1 is backwards compatible with API version 2.0.0. In these instances application developers simply need to increment the patch level digit in their application and retest.

The client calls a particular version by specifying the desired version in the request payload at run-time.

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 removal. 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 removal will be removed and the gateway will no longer accept requests from a deprecated API. Sabre strongly recommends regularly checking Sabre Dev Studio to see which APIs have been flagged for removal and 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.
The list of APIs flagged for removal 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 removal. You should then check your 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.