Start with the right client context.
Build an advisor experience around the workspaces a person is actually allowed to use—not a client name typed into a search box.
Inspect the access checkAccess first.
Client context second.
Choose an active workspace before requesting client information.
The returned workspace ID selects context. It never grants access.
Read the exact quickstartcurl https://api.smb.co/v1/me \
--header "Authorization: Bearer $SUPABASE_ACCESS_TOKEN"Membership, not blanket authority.
A successful current-access response identifies the active workspace memberships available to the authenticated user.
This example establishes an access check. It does not read client financials, approve an external action, or grant permission to every practice client.
Keep the boundaries
in the product.
A useful advisor experience explains missing access clearly and keeps one client’s information separate from another’s.
If the person cannot access a workspace
Keep the current request scoped to their actual memberships. Do not substitute a workspace ID, infer permission from an email address, or fall back to another client.
If the credential is missing or no longer valid
Use the documented authentication recovery path. Preserve the intended client context separately from credentials, and never display or log the secret.
For unattended practice work
The documented Workspace API key is pinned to one workspace. Store it as a secret. A key does not make client boundaries disappear.
Before you build a deeper operation
Inspect the current public or workspace projection, exact endpoint, permission, error contract, and commercial terms. This page does not promise a new batch endpoint or a practice-wide entitlement.
Inspect available business dataDocumentation describes the contract; it is not an end-to-end test using your account.