Migration Guide

Migration Options

The new Routehappy API provides two options for users of the legacy Routehappy Scores & Amenities (S&A) and Hub APIs. Either option will provide access to Amenities, UPAs, and UTAs data.

Option 1: Migrate to the Consolidated Endpoint

This option provides single-endpoint access to Amenities, UPAs, and UTAs along with a number of enhancements and improvements.

Option 2: Migrate to the Backwards Compatible Endpoints

This option allows you to continue to use the same requests and response processing with the performance benefits of the new Routehappy API. This option is recommended only for those users of the legacy S&A and/or Hub APIs who are not yet ready to migrate to the Consolidated Endpoint.

Migration Steps 1-4 - Either Option

Regardless of which option you select, you will need to follow the following four steps.

Step 1: Change the Request Header Parameter for Your API Key

The new Routehappy API uses the x-api-key request header parameter. This replaces the Auth parameter.

Previous

--header 'Auth: YOUR_ORIGINAL_API_KEY' \

New

--header 'x-api-key: YOUR_NEW_API_KEY' \

Step 2: Replace Your Original API Key with Your New API Key

Your new API Key was provided to you by ATPCO. Your original API Key will not be valid for use with the new Routehappy API. As a result, you must replace your original API Key with the new API Key.

Previous

--header 'x-api-key: YOUR_ORIGINAL_API_KEY' \

New

--header 'x-api-key: YOUR_NEW_API_KEY' \

Step 3: Obtain a Valid Access Token (Once Per Hour)

You will need to add a valid Access Token to your request header. Access Tokens expire after one hour, so you will need to obtain a new token at least once each hour you make a call to the new Routehappy API.

You can obtain a valid Access Token by submitting your client_id and client_secret to an Authorization API.

Your client_id, your client_secret, and the URL for the Authorization API were provided to you by ATPCO.

Example call to Authorization API

Assume your client_id is abcdefgh1234567890abijklmnopqrst, your client_secret is abcdefghijklmnopqrstuvwxyz, and the Access Token URL is https://access.token.url/. You will replace these values with the values ATPCO provided you.

curl --location --request POST 'https://access.token.url/' \
     --header 'Content-Type: application/x-www-form-urlencoded' \
	 --data-urlencode 'client_id=abcdefgh1234567890abijklmnopqrst' \
	 --data-urlencode 'client_secret=abcdefghijklmnopqrstuvwxyz' \
	 --data-urlencode 'grant_type=client_credentials'

{
	"access_token": "*********_an_access_token_*********",
	"token_type": "Bearer",
	"expires_in": 3600,
	"scope": "resource.WRITE resource.READ"
}​​​​​

Your Access Token is stored in the access_token field of the response.

Step 4: Add Your Access Token to the Request Header

Let's assume your valid access token is *********_an_access_token_*********.

Add an Authorization parameter to your request header with the following value: "Bearer" + space + your access token. For example:

--header 'Authorization: Bearer *********_an_access_token_*********'

Migration Step 5 - Option 1: Migrate to the Consolidated Endpoint

Change request and response processing

The Consolidated Endpoint's schema contains much the same structure for flights as the legacy Routehappy APIs. The field names are different, however. Please review the schema for the consolidated API and modify your code to ensure that your request and response processing is consistent with the new schema.

Migration Step 5 - Option 2: Migrate to the Backwards Compatible Endpoints

Change the Endpoint URLs

Once you have updated your API Key header and added your valid Access Token to your request header, the only thing left to do is to change the endpoint URLs to the ones provided to you by ATPCO.