API Versioning

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. This guarantees that you have access to new features and functionality that may have been introduced since your initial development.

View the release notes site for the latest updates and enhancements.

Retirement Schedule

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.

Sabre APIs

API Name Action Code / URI Version Type Date
Air Fare by City Pairs FareLLSRQ 1.10.1 - 2.2.0 SOAP July 31, 2018
Orchestrated Air Booking Enhanced_AirBookRQ 1.x.x SOAP September 07, 2018
Orchestrated Air Booking
Enhanced_AirBookWithTaxRQ 1.x.x SOAP September 07, 2018
Passenger Details PassengerDetailsRQ 1.x.x SOAP September 07, 2018
Passenger Details PassengerDetailsRQ 2.x.x - 3.0.0 SOAP September 28, 2018
Orchestrated Air Booking EnhancedAirBookRQ 2.x.x - 3.0.0 SOAP September 28, 2018
Rail RCP APIs Rail RCP APIs 1.18.1 SOAP September 28, 2018
Bargain Finder Max BargainFinderMaxRQ 1.0.1 - 1.9.7 SOAP October 31, 2018
Bargain Finder Max /shop/flights/ 1.0.1 - 1.9.7 REST October 31, 2018
Bargain Finder Max Shop Across Passenger Types BargainFinderMax_SAPTRQ 1.0.1 - 1.9.7 SOAP October 31, 2018
Bargain Finder Max Alternate Dates BargainFinderMax_ADRQ 1.0.1 - 1.9.7 SOAP October 31, 2018
Bargain Finder Max Alternate Dates /shop/altdates/flights/ 1.0.1 - 1.9.7 REST October 31, 2018
Bargain Finder Max Alternate Airport Shop BargainFinderMax_ASRQ 1.0.1 - 1.9.7 SOAP October 31, 2018
Bargain Finder Max Alternate Airport Shop /shop/altairports/flights/ 1.0.1 - 1.9.7 REST October 31, 2018
Get Itinerary
OTA_TravelItineraryReadLLSRQ
1.x.x
SOAP
October 31, 2018
Get Itinerary TravelItineraryReadLLSRQ 1.x.x - 2.x.x SOAP December 26, 2018
Auto Price Air Exchanges QREXLLSRQ 1.x.x SOAP December 26, 2018
Basic Fare Shop JR OTA_AirLowFareSearchLLSRQ 1.x.x - 2.x.x SOAP January 31, 2019
Get Itinerary TravelItineraryReadRQ 3.3.0 - 3.10.0 SOAP June 26, 2019
Display Seat Map IMAP_AirSeatMapLLSRQ 1.0.1 - 2.1.0 SOAP June 26, 2019
Basic Fare Shop BargainFinderPlusLLSRQ 1.x.x - 2.x.x SOAP June 30, 2019

Endpoints

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

Versioning

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.

Backward compatibility

Major (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 (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 (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. 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

Communications

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

Documentation

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
Major X X X X X
Minor X X X - -
Patch - X - - -

Frequently Asked Questions

Sabre APIs supports up to five of the most recent active versions. This covers the current "Live" version, minus 4 "Legacy" versions. When a new version of an API is introduced, the pre-existing version of that API will become a "Legacy" version. Any versions older than [n-4] will be slated for retirement. You should frequent the Retirement Schedule to determine whether an API is set to be retired.
Sabre maintains a Retirement Schedule of APIs flagged for removal from the system. Customers are expected to upgrade/migrate to the "Live" version of an API. Using the latest "Live" version guarantees access to the latest 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.
Retiring 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. "Legacy" versions older than [n-4] will be retired to support the current versioning policy.
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 retired, routing has been disabled and 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 to a supported version. If this occurs, the client application must be upgraded to use a newer version. Customers who have already upgraded their applications to bring their API version into compliance are unaffected by the retirement.
The list of APIs flagged for retirement will be updated on Sabre Dev Studio on a quarterly basis. See the Retirement Schedule for the list of APIs slated for retirement.
Sabre strongly recommends regularly checking Sabre Dev Studio to see which APIs have been flagged for retirement. You should check the version of the APIs you are currently using, and take appropriate steps to prepare for a migration if the version you are currently using is targeted for retirement. See the Retirement Schedule for the list of APIs slated for retirement.
Yes. Sabre teams are required to guarantee new APIs retain previous features and functionalities; however, new schemas may have been introduced to support new features and functionalities.