Authentication

Each request sent to Hilton’s APIs must include information that identifies the Client AppYour application, which will be sending requests to the Hilton API.
(Synonym(s) - API consumer, client application, mobile app, web app, application name)
. This enables the API to verify (i.e., authenticate) the identity of the calling application. Hilton offers two options for authentication – send the request with either the Bearer token or the base64-encoded client ID & client secret in the header. Which option your application should use depends on your specific needs, architecture, etc. If you are unsure which to use, please contact your API Coach.

Basic Authentication (Recommended Approach)
In basic authentication, each request contains a header field in the form of Authorization: Basic <credentials>, where credentials is the base64 encoding of client id and client secret joined by a single colon. For example, for client id “12345” and client secret “abcde”, you would encode “12345:abcde” and replace <credentials> with “MTIzNDU6YWJjZGU=”. This was encoded with Base64 Encode and Decode - Online, but any tool can be used.

Basic auth is the recommended approach.

For security reasons when passing username/password in the header it is highly recommended to transmit base64-encoded. For example,

POST /hospitality-partner/v2/dcres 
HTTP/1.1
Host: kapip-s.hilton.io

Content-Type: application/json

Authorization: Basic NGh-----Hd5
Here is a link to coding examples of how to set the base64 header in various languages: https://gist.github.com/brandonmwest/a2632d0a65088a20c00a
Token Authentication

This identification is controlled by an Access Token that is embedded into each API request header. The API will take the access token from the request, make sure that it is valid, and map it to the associated account.

Hilton's Authentication model is based on OAuth 2.01.

Authentication Flow Overview

Before you can connect to Hilton's APIs, you must have your application's Client IDA unique identifier for your Client App that is making requests to the Hilton API. This ID will be provided to you by Hilton.
(Synonym(s) - Consumer Key)
and Client SecretA secret passphrase that is used together with the assigned Client ID to prove that your Client App is authorized to make a request.
(Synonym(s) - Consumer Secret, Secret)
(i.e, your credentials).

Once you have your credentials, there are just 2 steps:

  • Generate a Temporary Access Token using the Credentials.
    • Submit Client ID and Client Secret to the Realms API for validation, and receive a temporary Access Token.
  • Generate a Platform API Request using the Access Token
    • Submit a platform API request which must include the temporary Access Token received in the previous step.
And we've also provided a few "Tips For Handling Authentication Failures" and a flow of the refresh process.

Have Your Client App's Credentials

You need two data elements to generate a valid access token – a client ID and a client secret. The client ID and client secret provide the ability to create temporary API access tokens on behalf of your application.

If you are a Hilton partner already, use your assigned client ID and client secret.

Not a partner yet? Building another application? Need access to an area not available to your Client App? Please request access

Generate a Temporary Access Token using the Credentials

The Realms API provides a temporary access token to allow your Client App to access Hilton's API. Send an authentication request to the Realms API (with valid credentials, of course), and an Access Token will be provided in response. The endpoint for the Realms API is /realms/applications/token

For example, to generate an access token for the staging environment, the URL would be:

https://kapip-s.hilton.io/hospitality-partner/v2/realms/applications/token

Here's a more robust example of the request and the response:

POST /hospitality-partner/v2/realms/applications/token
Host: kapip-s.hilton.io
Content-Type: application/json
Accept: application/json

{ 
  "client_id": "YOUR_CLIENT_ID",
  "client_secret": "YOUR_CLIENT_SECRET"
}

This request, if successful, will return the access token:

{
  "access_token": "8f59d3f20d3a8861ec2a083b7a09643d",
  "scope": "am_application_scope default",
  "token_type": "Bearer",
  "expires_in": 3600
}

The access token can then be used to make an API call on behalf of your application.

The endpoints you are allowed to call will depend on the needs of your application and your agreement with Hilton.

  • Use the same request (/realms/applications/token) again to request a new access token when the current one expires.
  • The expires_in value is provided in seconds (e.g., the 3600 in the example above means the access token will expire in 1 hour (i.e, 3600 seconds = 60 minutes = 1 hour).
  • When your access token expires, the response code of 401 Unauthorized with a response payload similar to the following will be received:
{
  "fault": {
    "code": 900901,
    "message": "Invalid Credentials",
    "description": "Access failure for API: /hospitality-partner/v2, version: v2. Make sure you have given the correct access token"
  }
}

Generate an API Request Using the Access Token

Send a request to the Platform API, with the access token obtained earlier (e.g. 8f59d3f20d3a8861ec2a083b7a09643d) in the Authorization request header, to make an application-level API request. For example:

GET /hospitality-partner/v2/dcshop/props
Content-Type: application/json
Accept: application/json
Authorization: Bearer 8f59d3f20d3a8861ec2a083b7a09643d

The Authorization header must be in the form of Authorization: Bearer YOUR ACCESS TOKEN GOES HERE

Tips For Handling Authentication Failures

If the request is not valid, the response returns the following error message:

{
  "error_description":"Missing parameters: client_secret",
  "error":"invalid_request"
}

If the request is not authorized due to invalid client id / client secret values, the response includes the following error message:

{
  "error_description":"Client Authentication failed",
  "error":"invalid_client"
}
You may also check the response code returned by the Realms service:
  • response code "401 - not authorized" signifies that there is a bad client id / client secret
  • response code "403 - forbidden" signifies that the credentials do not allow access to that specific endpoint
  • response code "503 - service unavailable" signifies that the Realms service is down

Writing Refresh Support Into Your Client App

The diagram below shows the overall workflow that your client app should use to
  1. obtain an access token
  2. detect if it has expired
  3. refresh the access token when needed: