Implementation and setup
Deliver value to travelers beyond points or miles
With White Label Template, your travelers can earn loyalty currency—however your program defines it—then redeem their rewards on travel purchases. This document provides an overview of the available Loyalty operations and explains the process for you to implement the services in the test and production environments.
You’ll provide standard RESTFul services with JSON payloads. We recommend using access tokens and JSON web tokens for every API request. There are additional security steps involved when calling the APIs, and any sensitive data elements in the request and response payloads will be encrypted.
When you set up your template site, you can choose to allow your customers to redeem any loyalty currency they’ve earned on whichever lines of business you’ve selected.
Alternatively, they can reach out to an Expedia brand site agent to use those points. Our internal agents will use the Account Information API to to verify the traveler’s information. Once verified, they will leverage the Points Bank API to get the traveler’s account balance and assist with booking.
Your Expedia launch manager will work with you to get all the necessary details, including SSO setup, such as: Your brand or program name, any member tiers or segments within your program, the name of your loyalty currency, and the redemption ratio (for example, $1 spent = 100 points).
We’ll also need you to provide:
- Access Token API
- ClientId and secret
- Loyalty redemption endpoints
- The service level agreement (SLA) you’ve communicated to your customers
For setup on your end, we’ll provide:
- An OpenAPI specification
- A JSON web key (JWK) endpoint if you’re using the Authorization2 parameter
Making API calls
Expedia uses the access token to invoke the API. The access token will be provided in the authorization HTTP header as a bearer token. The system will generate a required request signature token and provide that in the Authorization2 HTTP header.
Authorization endpoint
To get an access token for API calls, you’ll first need to set up an authorization server with a client ID and secret. Then you’ll use a POST : https://<your-oauth-endpoint> call to make the request.
Request
| Field | Description | Sample value | Field type | Mandatory? |
|---|---|---|---|---|
content-type | Indicates the request format | application/x-www-form-urlencoded | String | Yes |
grant_type | Method of authorization for the request, such as client credentials | client-credentials&client_id=<client_id>&client_secret=<client_secret> | String | Yes |
client_id | Your application identifier as registered | a17c21ed& | Yes | |
client_secret | Secret corresponding to the client_id | Yes |
Response
| Field | Description | Sample value | Field type | Mandatory? |
|---|---|---|---|---|
content-type | Indicates the response body format | application/json | String | Yes |
token_type | The audience of the token; indicates the kind of access to provide | bearer | Yes | |
access_token | An access token referencing the client_id | Yes | ||
expires_in | The expiration time of the access token in seconds | 86400 | Yes |
Errors
| Field | Description | Sample value | Field type | Mandatory? |
|---|---|---|---|---|
error | An error has occurred, such as an invalid parameter | invalid_request invalid_client invalid_grant | String | Yes |
errorMessage | Custom error message used to assist in logging and issue investigation | String | Yes |
JWK endpoint response
We’ll share a URL where you can fetch JWKs to use for verification. For example: GET : https:// <WLT_Domain>/keys/public-keys --header Authorization : Bearer - Partner_client_api_key
| Field | Description |
|---|---|
alg | Signature algorithm |
kty | Crypto key type |
kid | Key identifier |
use | How the key is meant to be used: for signature (sig) or encryption (enc) |
x5t | X.509 certificate thumbprint |
x5c | X.509 certificate chain |
expires_on | Certificate expiration date |
Request signing
We recommend that every API request be signed using a JSON web token (JWT). The steps for signing requests are:
- We’ll set up 2048 bit CA signed RSA private key.
- We’ll publish the public certificate via a JWK URL (as mentioned above).
- We’ll then create a JWT token with issuer, subject, audience, and expiration claims and sign the token using the private key.
- The Expedia JWT token will have the key identifiers kid and x5t, which contain the public key certificate’s thumbprint.
- When performing an API call, you’ll extract the JWT from the authorization headers and validate the JWT signature using Expedia’s public key. You’ll identify the key (in case multiple keys are present in Expedia’s JWK URL) using the kid header.
- Next, you’ll schedule an API call to Expedia’s JWK endpoint to fetch the public key certificate.
- You should also use retry logic to fetch new certificate if the signature validation fails.