Skip to content
Quikstik Developers

Tenants and keys

A tenant is one operator: one catalog, one set of bookings, one ledger, one team. Everything in the API is scoped to a tenant, and the tenant is always derived from the credential you present, never from a field in the request.

  • With a publishable or operator key, you send the tenant id in x-tenant-id and the key is verified against it. A mismatch is 401 invalid_key.
  • With a session, the tenant is inside the token. There is no header to send and no way to point a session at another tenant.
  • With a content key, the tenant is resolved from the merchant_slug in the path and the key is checked against it.
  • With a capability token in a guest link, the token itself identifies one tenant’s one booking.

Readers are tenant-scoped at the storage layer, so another tenant’s rows are not just forbidden but structurally invisible: asking for a booking id that belongs to someone else returns 404, not 403. Content tables additionally enforce row-level security, and stored payment credentials bind the tenant into their encryption so a credential cannot be replayed across tenants.

Tenant id and merchant slug

Section titled “Tenant id and merchant slug”

A tenant has a UUID (x-tenant-id) and, where it has a storefront, a human merchant slug used in content URLs (/merchants/{merchant_slug}/…). The slug never enters the domain — it is translated to the tenant at the edge.

Multiple tenants in one integration

Section titled “Multiple tenants in one integration”

If you serve several operators (an agency, a marketplace, a reseller), hold one credential per tenant and send the matching x-tenant-id per request. Do not try to reuse a key across tenants; by construction it will not work.

Actors

Section titled “Actors”

Every write is attributed to an actor: the staff member behind a session, the member who minted an operator key, or — for storefront purchases — the anonymous storefront. Audit trails, the heartbeat and the ledger all carry the actor, which is why an operator key dies with the membership of the person who minted it.

Vocabulary is per tenant

Section titled “Vocabulary is per tenant”

Quikstik is built for any slot-based business, so the fixed states in the system (a booking is booked, checked in, done, cancelled or no-show) are rendered with per-tenant words. The API returns the fixed vocabulary; the tenant’s display terms are available from its settings. Do not hard-code “rider” or “tour” in an integration meant for more than one tenant.