Authentication and scopes

Create a scoped key, restrict its resources and manage its lifecycle.

Send a bearer credential

Send Authorization: Bearer YOUR_API_KEY on every request. Keep credentials on your server; do not embed production keys in public websites, mobile clients, URLs or documentation consoles. External routes do not authenticate with dashboard cookies.

Keys are shown once. A verified manager with an active full account can manage tenant integrations. Employee work accounts and attached staff sessions cannot issue credentials.

text

Authorization: Bearer lb_sk_PUBLIC_ID_SECRET

Choose only the scopes you need

waitlist:read: Discover businesses, lines, services and entries.

waitlist:write: Create guests and bookings and update supported entry fields or statuses.

guest:read: Read guest names, phone numbers and public custom-field values.

events:read: Read the immutable event feed for authorized resources.

webhooks:read: Read webhook subscriptions and redacted delivery metadata.

webhooks:write: Create, update and disconnect subscriptions and request tests or retries.

analytics:read: Read tenant and business line summaries.

Restrict businesses and lines

Every key belongs to one tenant. Optional business and line restrictions narrow its resource access. A scope is permission to perform specific operations. It applies only within those restrictions. A reference to an inaccessible business, line, service, entry or subscription does not grant access to it.

New keys require guest:read for guest identity and contact fields. Existing legacy consumers must follow the recorded compatibility transition before fields or scopes are narrowed.

Expire, rotate and revoke

New keys default to 90 days and may last at most 365 days. Rotation creates a new one-time key; update the consuming system during the displayed overlap, then revoke the old key. Never paste the secret into support messages.

Expiry, revocation, creator removal or loss of creator authority prevents further use. The server also checks current billing eligibility on each production request. Unrevoked keys may work again after access is restored; revoked keys never reactivate.

Managers who lose production access can still inspect redacted metadata, revoke keys and disconnect subscriptions. A cancelled recurring plan follows its paid-through-period-end access policy.