EDistribution API

Authentication#

Every request carries your API key as the Basic auth username, with an empty password.

That shape is deliberate: every HTTP client on earth already knows how to do Basic auth, so there is nothing to hand-roll. In cURL it is -u "$KEY:" — the trailing colon is what makes the password empty.

The header your client ends up sending is Authorization: Basic <base64("<key>:")>.

cURL
curl "$BASE/v1/ping" -u "$ELIVAAS_API_KEY:"

The key is the tenant#

This is the single most important thing on this page, and it shapes every payload in the API.

Your key resolves to exactly one account and one channel. Everything else follows:

  • No request takes an account id, channel id, agent id or user id. Not in a path, not in a query string, not in a body. There is no field for one, and inventing one changes nothing.
  • Reads are scoped in SQL, not filtered after the fetch. Another account's row is not fetched and then hidden; it is never selected.
  • A resource you cannot see is a 404, worded identically to one that does not exist. You cannot use this API to probe whether an id exists outside your own account. See Errors.

The practical consequence: you cannot act on behalf of a sub-account by passing an id. If you need separate scopes — different brands, different credit lines — you need separate accounts, each with its own key. Ask us.

Confirming which key is live#

GET /v1/ping returns the account and key prefix the request authenticated as. It is the fastest way to answer "which key is this deployment actually using?" without exposing the key itself.

keyPrefix is the first 12 characters. It is safe to log and safe to show in an admin screen — the full key is never recoverable after issue, not by you and not by us.

Issue a separate key per deployment so this is meaningful. See multiple keys.

200
{
  "agentGroupId": 42,
  "agentGroupName": "Example Travel Pvt Ltd",
  "channelId": "B2B_EXAMPLE",
  "keyPrefix": "dk_live_9fQ"
}

Handling 401#

A 401 means one of four things, and the response is identical for all four — telling them apart would tell an attacker which guess was closer:

No Authorization header, or a malformed one
The key does not exist
The key was revoked
The account's distribution access is DISABLED
json
{
  "status": 401,
  "error": "Unauthorized",
  "message": "Invalid API key",
  "path": "/v1/listings",
  "timestamp": "2026-07-29T13:05:56.198280408Z"
}

Never retry a 401. It will fail identically. Treat it as a configuration fault, alert, and stop.

Storing the key#

  • Secret manager, not a config file. The key is a bearer credential: anyone holding it can book against your credit line.
  • Never ship it to a browser. There is no public/publishable variant of this key. All calls are server-to-server.
  • Rotate by issuing then revoking, in that order — an account can hold several active keys at once, so there is no downtime. See rolling a key.
  • It is shown exactly once. We store only a SHA-256 hash. A lost key is replaced, never recovered.

Next#

Call GET /v1/ping, then walk the Quickstart.