Skip to content

Channel Manager Authentication

Every /v1/channel-manager/pms/* call is authenticated with two headers:

X-PMS-API-Key: YOUR_PMS_API_KEY
X-PMS-API-Secret: YOUR_PMS_API_SECRET

The tenant/property is always resolved from the credential — never sent as a request parameter.

This is the same shape as the Third-Party API’s X-API-Key/X-API-Secret scheme, with different header names and a separate, independent credential namespace — a Channel Manager PMS credential does not work against /v1/third-party/*, and vice versa.

Owner authentication (credential management)

Section titled “Owner authentication (credential management)”

Credentials are issued via the owner-facing POST /v1/channel-manager/pms-credentials/ endpoint, which is JWT-authenticated and owner-only — the same pattern as the Third-Party API’s /v1/third-party/credentials/. This endpoint is intentionally excluded from the public Channel Manager schema (it isn’t part of the PMS-facing contract), so it isn’t shown in the interactive reference here.

Confirmed from the backend’s credential service (same mechanism as the Third-Party API’s):

  • Issue: mints a new api_key + api_secret, secret shown once.
  • Rotate: issues a new api_secret; the api_key is unchanged. The previous secret stops working immediately — there is no grace period.
  • Revoke: deactivates the credential (is_active = false); an inactive credential is rejected the same as an unknown one (see below).
Terminal window
curl https://api.restrolab.com/v1/channel-manager/pms/properties/ \
-H "X-PMS-API-Key: YOUR_PMS_API_KEY" \
-H "X-PMS-API-Secret: YOUR_PMS_API_SECRET"
Status Meaning Response body
401 Unauthorized Missing, unknown, or inactive X-PMS-API-Key, or a wrong X-PMS-API-Secret. {"code": "invalid_credentials", "message": "Invalid PMS credentials."}

This uses the same {"code": ..., "message": ...} envelope as the Third-Party API’s errors (confirmed from the backend’s shared exception handler), including invalid_request for validation errors and rate_limited for throttling — see Overview for the confirmed rate limit.

Tenant isolation is enforced at this layer too: a valid credential only ever sees its own tenant’s properties, inventory, rates, and reservations — never another tenant’s, even by guessing ids.