Authentication

Every request carries an API key in the Authorization header:

Authorization: Bearer lp_live_XXXXXXXX…    (workspace key)
Authorization: Bearer lpp_live_XXXXXXXX…   (partner key)

Keys are created in the dashboard, shown once at creation and stored as a SHA-256 hash — nobody, including support, can recover a lost key. Losing a key means revoking it and creating a new one.

Key kinds

• Workspace keys (lp_live_…) act inside one workspace: links, analytics, domains, the audit trail and workspace webhooks. Created by workspace admins in Settings → API keys.
• Partner keys (lpp_live_…) act on the partner account: clients, plans, domains, payments, payouts and partner webhooks. Created by partner admins.

A workspace key calling /partner/* (or vice versa) gets 403 forbidden — the endpoint families are strictly separated.

Scopes

Scopes are granted per key at creation. A request needs every scope its endpoint requires; a missing scope answers 403 insufficient_scope naming the missing scope.

| Scope | Grants | |---|---| | links:read / links:write | Read / create, update, archive, delete links | | analytics:read | Summary, timeseries, breakdowns, top links, CSV export — and the partner-wide clicks overview | | domains:read / domains:write | Read / connect and disconnect domains | | qr:read | Render QR codes of links | | workspace:read | Workspace profile, limits, audit trail | | webhooks:read / webhooks:write | Read / manage webhook endpoints | | partner:read | Partner profile, plan and usage | | clients:read / clients:write | Read / create, change, suspend clients | | plans:read / plans:write | Read / manage partner plans | | payments:read | Payments mirror and payouts |

That is the complete list — fifteen scopes, and a key can only hold names from it. QR codes are read-only over the API: rendering one needs qr:read, and there is no QR write scope because there is no QR mutation endpoint.

One pairing catches people out: GET /partner/analytics/overview needs analytics:read on the partner key, not partner:read. Every analytics endpoint uses the same scope regardless of key kind.

Give each integration its own key with the minimum scopes it needs: a dashboard-widget key does fine with links:read + analytics:read, while a provisioning script needs clients:write.

Plan gating

API access is a plan feature (api_access):

• for workspace keys both the workspace plan and the partner’s platform plan must include API access;
• for partner keys the partner’s platform plan must include it.

A plan without API access answers 403 plan_restricted. Trial workspaces without a plan are not restricted.

Rotation and revocation

Revoking a key takes effect immediately: the next request answers 401 unauthorized. To rotate without downtime, create the new key first, switch the integration, then revoke the old one. Each key records last_used_at, so an unused old key is easy to spot before revoking.

Optionally a key can carry an expiry date — expired keys behave exactly like revoked ones.

Good practice

• Keys are secrets: keep them in a secret manager, never in client-side code, repositories or logs.
• One key per integration — revoking one does not break the others, and the audit trail attributes every change to the key that made it.