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.