Skip to content
Log in
Authentication

Authentication

Every authenticated request carries a Bearer API key. The key identifies the property you are acting on and the scopes you may use. There are no usernames, passwords, or OAuth flows: one key per integration.

The key format

A Veridien API key starts with vrdn_live_, followed by 40 letters and digits. This reference writes it as YOUR_API_KEY.

  • It is shown once, when you create it. Veridien stores only a SHA-256 hash of the key, so it can never be shown again, only revoked and replaced.
  • It is bound to one property. The property comes from the key, so no endpoint asks you for a property id.
  • It can carry an expiry date. Without one, it never expires.

Treat keys like passwords

A key grants its scopes against your live property data. Keep it in a server-side secret store or environment variable, never in client-side code or a public repository. If a key leaks, revoke it at once and create a new one.

Creating a key

You create keys in the dashboard under Settings → API keys. You need the permission to manage API keys.

  1. Click Create key and give the key a name you will recognise (for example, Sunrise Bay website).
  2. Choose the scopes the integration needs, and only those.
  3. Optionally set an expiry date. Requests are rejected from the end of that day.
  4. Copy the key from the confirmation dialog and store it securely. It is not shown again.

You can revoke a key at any time from the same screen. A revoked key stops working at once, and requests that use it return 401.

Sending the key

Put the key in the Authorization header on every request:

curl https://veridien.app/api/v1/me \
  -H "Authorization: Bearer YOUR_API_KEY"

If the header is missing or malformed you get 401 missing_api_key. If the key is unknown, revoked, or expired you get 401 invalid_api_key. You also get 401 invalid_api_key while the property is not yet verified, is suspended, or does not have the API module on its plan.

Check your key

GET /me

Scope: none. Any valid key may call it.

Returns the property the key is bound to and the scopes it holds. Call it first to confirm a key works.

{
  "property_id": "4e1b7c2a-9d3f-4a6e-8b5c-0f2d7a9e3c18",
  "property_slug": "sunrise-bay",
  "scopes": ["availability:read", "reservations:write", "folio:write"],
  "request_id": "req_0b9d3e6a-2f4c-4a1e-9c7b-5d8f1a3e6b20"
}
FieldTypeNotes
property_idstringThe property's id (a UUID).
property_slugstringThe property's URL slug.
scopesarrayThe scopes this key holds.
request_idstringThis request's id.

Scopes

A key may only call an endpoint if it holds that endpoint's scope. Calling an endpoint without its scope returns 403 insufficient_scope. Scopes follow a resource:action shape.

ScopeGrants
availability:readRead the property and catalog: /property, /room-types, /availability, /rates, /services, GET /rate-plans, and POST /promo-codes/validate.
rates:readRead rate-management resources: GET /rate-plans/{id}/intervals, /inclusions, and /promo-codes.
rates:writeCreate, update, and delete rate plans and promotions, seasonal intervals, inclusions and credits, and promo codes.
reservations:readList and read reservations (/reservations, /reservations/{id}).
reservations:writeCreate holds, confirm them, and cancel reservations (/holds, /holds/{id}/confirm, /reservations/{id}/cancel).
guests:readRead guest profiles, without personal data.
guests:read:piiAlso return guest personal data (email, phone, date of birth, ID document).
guests:writeRegister, link, and update guests (POST /guests, PATCH /guests/{id}).
loyalty:readRead a guest's loyalty balance, tier, and ledger.
loyalty:writeRedeem loyalty points (/loyalty/redemptions).
folio:readRead a reservation's folio.
folio:writePost charges to a folio (/reservations/{id}/folio/charges).
webhooks:manageReserved for webhook subscription management. No endpoint uses it yet.

Least privilege

Grant only the scopes an integration needs. A read-only availability display needs just availability:read. A full booking flow typically needs availability:read, guests:write, reservations:write, and folio:write, plus the loyalty scopes if it shows points.

PII and guest data

Guest profiles come in a base view and a personal-data view. With guests:read you receive ids and non-sensitive fields (name, nationality, the local-verification flag). To also receive email, phone, date_of_birth, id_type, and id_number, the key must also hold guests:read:pii. That lets you build, say, a widget that reads a guest's name without ever exposing contact details.

Public endpoints

Two meta endpoints need no key and no scope:

  • GET /health: a liveness probe that returns { "status": "ok" }.
  • GET /openapi.json: the OpenAPI 3.1 schema for the whole API.

Everything else needs a valid key with the right scope.

  • Conventions: errors, idempotency, pagination, and rate limits.
  • Quickstart: a complete booking flow from key to confirmed reservation.