Getting started
Authentication
Every request carries an API key as a bearer token. Keys are created by the business owner and carry only the permissions they were given.
GET /api/v1/services HTTP/1.1
Authorization: Bearer lb_sk_YOUR_KEYOnly the Bearer scheme is accepted, and a bare token with no scheme is refused — there is exactly one documented way to authenticate. A missing or malformed header returns 401 with a WWW-Authenticate header, so a generic HTTP client knows what this endpoint wants.
Creating a key
In the console: Settings → API and MCP. Owner-only — a key can read every client’s contact details and, with the write scope, put appointments in the diary, so issuing one is a decision about who may act for the business.
Shown once, and only once
Only a SHA-256 fingerprint of the key is stored. The token itself is written nowhere, so there is no “reveal” to come back to and support cannot recover it for you. If it is lost, revoke it and mint another.
Keys look like lb_sk_ followed by 43 URL-safe characters — 32 bytes of randomness. The prefix is deliberate: secret-scanning tools match on a stable marker, so a key pasted into a public repository can be found. The console shows the first 14 characters of each key so you can tell two apart; that is safe to quote in a support conversation.
Scopes
Ask for the least you need. An integration refused one scope keeps working for everything else it can do, and a key minted for a reporting dashboard has no business holding bookings:write.
| Scope | What it opens |
|---|---|
catalog:read | Read services, team and locations |
availability:read | Read open booking times |
bookings:read | Read appointmentspersonal data |
bookings:write | Create, move and cancel bookings |
customers:read | Read client names and contact detailspersonal data |
The two marked personal data return information about people who booked with the business — not about the business. They are separate scopes for that reason, and the settings screen marks them so the decision does not look like the others.
Calling an endpoint your key lacks the scope for returns 403 forbidden, and the message names the scopes the key does hold. That is distinct from 401: retrying a 401 with a different key can work, retrying a 403 with the same key never will.
Revocation and plan changes
- Revoking a key in the console takes effect on the very next request, on both REST and MCP. There is no cached session to expire.
- The plan is re-read on every request. A key minted on a paid plan stops working if the business downgrades, and starts working again on upgrade — the same key, no rotation.
- Revoked, expired and unknown keys all return the same
401message. Distinguishing them would confirm to a stranger that a particular key exists.
Keep keys server-side
A key carries the permissions you gave it for as long as it exists. Do not ship one in a browser bundle, a mobile app or anything else a user can read — put it behind your own server, and revoke immediately if it leaks.
Rate limits and quotas are per key. See Errors and limits.