Authentication
Requests are authenticated with two headers. There is no bearer token and no login call for API partners.
| Header | Use |
|---|---|
| apikey | Required on every request. |
| secretecode | Required on every request. |
| ipaddress | Context about the end user's client. See below. |
| browsername | Context about the end user's client. See below. |
| browserversion | Context about the end user's client. See below. |
| platform | Context about the end user's client. See below. |
| os | Context about the end user's client. See below. |
| domain | Context about the end user's client. See below. |
curl -X POST "$BASE_URL/flight/search" \
-H "Content-Type: application/json" \
-H "apikey: $API_KEY" \
-H "secretecode: $SECRET_CODE" \
-d @payload.json
Keep the keys safe
- Call the API from your server. Anyone with both headers can act as you.
- Read the keys from environment variables or a secret store, not from source code.
- If a key leaks, ask your account manager to rotate it.
Context headers
The context headers describe the end user's device: ipaddress, browsername, browserversion, platform, os and domain. Our own web portals send them on every call. When you book on behalf of a customer, pass the values from the customer's browser.
Failed authentication
A missing or wrong key does not return HTTP 401. It returns HTTP 200 with a failed body:
{ "status": "failed", "code": 401, "reason": "Invalid access key" }
Check status on every response. See Errors.