Migration Guide - GeoAutocomplete v1 to v2
What is the Autocomplete API?
The API uses the full word or substring (minimum 3 characters) to search across all locations to match against a geographic search query. A location can be an airport, city, rail station, or various other points of interest (POI).
For example, if "Dall" is typed, then "Dallas/Fort Worth International" and "Dallas Love Field" airport information will be returned.
Making use of the Autocomplete API
To make an API call to Autocomplete V2, the following information needs to be provided:
query – The word to be autocompleted. This value must contain a minimum of 3 characters so that the API can retrieve location information.
category – Tells the API the type of location info to retrieve. Can be AIR, CITY, RAIL, LOCATION, POI.
limit – The number of search results to display. If no value is entered, the default is 5
.
Why are we sunsetting Autocomplete V1?
As part of the roadmap for Legacy GEO sunset, we are requesting all users to migrate to our NGGP (Next Generation Geo Platform) Services API - Autocomplete V2 which supports all functionalities as V1 and will be served from the Next Generation systems.
Migration Guide Summary
API Information
|
|
|
|
|
|
|
What's New?
Autocomplete V2 has a few enhancements when compared to V1:
- Autocomplete V2 will be served from the Next Generation Systems - NGGP (Next Generation Geo Platform) Services as we are sunsetting the legacy Geo application.
- Autocomplete V2 will be available in Google Cloud Platform (GCP) as part of the NGGP-Services Application.
- Autocomplete V2 supports custom ranking to improve customer experience.
- Active support is provided as Autocomplete V2 is now served from the Next Generation Systems.
|
Existing URL | Type of Customer |
Proposed URL |
---|---|---|
Geoservices.sabre.com |
INTERNAL | http://api.internal.prod.ha.sabre.com |
EXTERNAL |
https://api.havail.sabre.com | |
api.havail.sabre.com |
INTERNAL |
http://api.internal.prod.ha.sabre.com |
EXTERNAL |
https://api.havail.sabre.com | |
api.internal.prod.ha.sabre.com |
INTERNAL |
http://api.internal.prod.ha.sabre.com |
EXTERNAL |
https://api.havail.sabre.com |
Certification / CERT
Existing URL | Type of Customer |
Proposed URL |
---|---|---|
Geoservices.cert.sabre.com |
INTERNAL | |
EXTERNAL |
https://api-crt.cert.havail.sabre.com | |
api-crt.cert.havail.sabre.com |
INTERNAL |
http://api.cert.ha.sabre.com |
EXTERNAL |
https://api-crt.cert.havail.sabre.com | |
api.cert.ha.sabre.com |
INTERNAL |
http://api.cert.ha.sabre.com |
EXTERNAL |
https://api-crt.cert.havail.sabre.com |
Integration / INT
Existing URL | Type of Customer |
Proposed URL |
---|---|---|
geoservices.dev.sabre.com |
INTERNAL | |
EXTERNAL |
https://api.tsts.havail.sabre.com | |
api.tsts.havail.sabre.com |
INTERNAL |
http://api.tsts.ha.sabre.com |
EXTERNAL |
https://api.tsts.havail.sabre.com | |
api.tsts.ha.sabre.com |
INTERNAL |
http://api.tsts.ha.sabre.com |
EXTERNAL |
https://api.tsts.havail.sabre.com |
For further details, you can refer - Sabre Endpoints
If you used to access Autocomplete V1 via the geoservices.*(.sabre.com) URL, then please follow the steps mentioned below to ensure a seamless migration to Autocomplete V2.
Otherwise, you can skip to the next section.
Migrating to Autocomplete V2 – geoservices.*(.sabre.com) users
1. Creating a 2SG Token to authenticate API requests
In order to make use of the Autocomplete V2 API via 2SG, the user needs to be authenticated by creating a token before firing any API requests.
To create a 2SG token, a POST request must be fired to - https://webservices.havail.sabre.com, along with a bearer token in the header.
You can refer to the following link to generate the token:
https://developer.sabre.com/guides/travel-agency/quickstart-guides/get-token
2. Modification in endpoint
Autocomplete V1 |
Autocomplete V2 |
/autocomplete/v1/select |
/v2/geo/autocomplete |
/v1/lists/utilities/geoservices/autocomplete |
/v2/geo/autocomplete |
So, the URL to hit the API that earlier looked something like this in
V1 - https://geoservices.sabre.com/autocomplete/v1/select
will now look like this in
V2 - https://api.havail.sabre.com/v2/geo/autocomplete
Migrating to Autocomplete V2 – if accessing V1 via 2SG
1. Modification in endpoint
If you accessed Autocomplete V1 via 2SG (through https://api.havail.sabre.com or http://api.internal.prod.ha.sabre.com), then there is a change in URL endpoint needed from your end to migrate to Autocomplete V2.
Autocomplete V1 |
Autocomplete V2 |
/autocomplete/v1/select |
/v2/geo/autocomplete |
/v1/lists/utilities/geoservices/autocomplete |
/v2/geo/autocomplete |
This is how the URLs will look in V2 as compared to V1:
V1 - https://api.havail.sabre.com/v1/lists/utilities/geoservices/autocomplete
V2 - https://api.havail.sabre.com/v2/geo/autocomplete
2. Change in response structure
There is a minor change in response structure that we observe in Autocomplete V2, when compared to V1.
To illustrate this difference, let us consider a sample request where we look for autocomplete result for airports, using the query term – ‘DFW’
Request:
V1: https://geoservices.sabre.com/autocomplete/v1/select?query=DFW&limit=5&clientId=geo&category=AIR
V2: https://api.havail.sabre.com/v2/geo/autocomplete?query=DFW&limit=5&clientId=geo&category=AIR
Response - Autocomplete V1 vs Autocomplete V2
As visible in the images above:
1. Autocomplete V2 no longer returns the ‘Links’ object as part of the response.
2. In Autocomplete V1, the ‘responseHeader’ and ‘grouped’ objects were enclosed inside a
‘Response’ object. This is no longer the case in Autocomplete V2, wherein the response
directly contains the ‘responseHeader’ and ‘grouped’ objects.
Summary
A 2SG user is someone who used to access Autocomplete V1 via 2SG as well (using api.havail.sabre.com or api.internal.prod.ha.sabre.com).
A non 2SG user is someone who used to access Autocomplete V1 directly, without routing via 2SG (using geoservices.*(.sabre.com))