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 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 October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Bargain Finder Max /shop/flights/ 1.0.1 - 1.9.7 REST October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Bargain Finder Max Shop Across Passenger Types BargainFinderMax_SAPTRQ 1.0.1 - 1.9.7 SOAP October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Bargain Finder Max Alternate Dates BargainFinderMax_ADRQ 1.0.1 - 1.9.7 SOAP October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Bargain Finder Max Alternate Dates /shop/altdates/flights/ 1.0.1 - 1.9.7 REST October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Bargain Finder Max Alternate Airport Shop BargainFinderMax_ASRQ 1.0.1 - 1.9.7 SOAP October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Bargain Finder Max Alternate Airport Shop /shop/altairports/flights/ 1.0.1 - 1.9.7 REST October 31, 2018, 3am-4am CT November 14, 2018 November 07, 2018, 3am-4am CT November 29, 2018
Air Fare by City Pairs FareLLSRQ 1.10.1 - 2.2.0 SOAP October 31, 2018, 5am-6am CT November 14, 2018 November 09, 2018, 3am-4am CT November 29, 2018
Orchestrated Air Booking Enhanced_AirBookRQ 1.x.x SOAP October 31, 2018, 5am-6am CT November 14, 2018 November 09, 2018, 3am-4am CT November 29, 2018
Orchestrated Air Booking
Enhanced_AirBookWithTaxRQ 1.x.x SOAP October 31, 2018, 5am-6am CT November 14, 2018 November 09, 2018, 3am-4am CT November 29, 2018
Passenger Details PassengerDetailsRQ 1.x.x SOAP October 31, 2018, 5am-6am CT November 14, 2018 November 09, 2018, 3am-4am CT November 29, 2018
Passenger Details PassengerDetailsRQ 2.x.x - 3.0.0 SOAP October 31, 2018, 5am-6am CT November 14, 2018 November 09, 2018, 3am-4am CT November 29, 2018
Orchestrated Air Booking EnhancedAirBookRQ 2.x.x - 3.0.0 SOAP October 31, 2018, 5am-6am CT November 14, 2018 November 09, 2018, 3am-4am CT November 29, 2018
Rail RCP APIs Rail RCP APIs 1.19.0 SOAP TBD TBD TBD December 15, 2018
Auto Price Air Exchanges QREXLLSRQ 1.x.x SOAP TBD TBD TBD December 26, 2018
Get Itinerary OTA_TravelItineraryReadLLSRQ 1.x.x SOAP TBD November 14, 2018 TBD January 15, 2019
Rail RCP APIs Rail RCP APIs 1.20.0 SOAP TBD TBD TBD January 30, 2019
Basic Fare Shop JR OTA_AirLowFareSearchLLSRQ 1.x.x - 2.x.x SOAP TBD TBD TBD January 31, 2019
Get Itinerary TravelItineraryReadLLSRQ 1.x.x - 2.x.x SOAP TBD February 14, 2019 TBD March 14, 2019
Get Itinerary TravelItineraryReadRQ 3.3.0 SOAP TBD February 14, 2019 TBD March 14, 2019
Get Itinerary TravelItineraryReadRQ 3.4.0 - 3.9.0 SOAP TBD June 03, 2019 TBD June 26, 2019
Display Seat Map IMAP_AirSeatMapLLSRQ 1.0.1 - 2.1.0 SOAP TBD TBD TBD June 26, 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

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