Skip to main content
Everything goes in Authorization. An API key and a session token resolve to the same account and behave identically. Nothing you can do with one is unavailable through the other.

​
API keys

Mint one with POST /api/billing/claim. The raw key is returned exactly once and stored only as a hash, so we cannot show it to you again or recover it — which is also why the endpoint refuses if your account already has a live key. Silently minting a second would leave you holding a credential you had no way to tell apart from the first, or to revoke with confidence.
A key can repoint every code on the account, including ones already printed on physical material. Treat it like a production database credential, not like an analytics token.

​
Workspaces

An account is a workspace. Members you invite create links that belong to the workspace, not to themselves — being invited is delegation of the owner’s account, never a free account of your own. A session token that can reach several workspaces selects one with X-Workspace-Id. An API key belongs to exactly one workspace and ignores the header; GET /api/workspaces reports the one it is scoped to.
Asking for a workspace you are not a member of is a 401, decided before anything else about the request is considered.

​
What authentication does not decide

Authentication answers “who are you”. It never answers “may you”. Those are separate on purpose, and the gap is where the product promise lives: a cancelled customer signs in normally, lists their links, downloads artwork for codes they printed years ago, and reaches the billing portal. What they cannot do is create or edit. See Errors for how that is reported, and Permanence for why.