Concepts
Vocabulary for sign-in, sessions, and API tokens. Organization SSO and membership rules are covered briefly — full org admin flows will get their own guide later.
Platform vs organization vs workspace
| Layer | Role for you |
|---|---|
| Platform | Authenticates you once (email/password, SSO, MFA) |
| Organization | Policy boundary — SSO, password rules, MFA requirements |
| Workspace | Where product data lives (Capture, Performance, …) |
Your Account settings are personal. Changing org settings requires Organization admin — not covered here.
Browser sessions vs API tokens
| Browser session | API token | |
|---|---|---|
| Created by | Sign-in in the app | Account → API tokens |
| Used by | The web UI (cookie) | CLI, CI, scripts (Authorization: Bearer) |
| Visible secret | No — HttpOnly cookie | Yes — sl_… shown once at mint |
| Revoke | Sessions or sign out | API tokens → Revoke |
| Scopes | Full UI access for your memberships | Explicit permission list |
Treat API tokens like passwords. Prefer scoped, expiring tokens over long-lived full-access tokens.
Token scopes {#token-scopes}
Each token carries a list of scopes — what HTTP APIs it may call. Scopes are grouped by product area:
| Area | Read allows… | Write allows… |
|---|---|---|
| Platform | Orgs, workspaces, members, account metadata | Mutations on those resources |
| Performance | Runs, scenarios, collections, reports | Create runs, upload artifacts |
| Capture | Inboxes (sessions), request history | Create/update capture sessions |
Write implies read within the same area. Granting performance:write automatically includes read access to Performance APIs.
Presets (quick picks)
| Preset | Scopes (summary) |
|---|---|
| CLI / CI | Platform read · Performance read+write · Capture read |
| Read-only | Read on all three areas |
| Full access | Full (*) on all three areas |
| Custom | You choose per area |
Wildcards like performance:* mean full access to that area. The global * wildcard is not available for user-minted tokens.
What scopes do not do
- Scopes do not grant org admin powers you do not already have through membership.
- Scopes do not replace workspace membership — you still need access to the workspace.
- A token with only Capture read cannot start Performance runs (you will see insufficient scope errors).
Workspace restriction
When Restrict token to … is enabled at creation time, the token is pinned to the current workspace. API calls that target another workspace are rejected even if your user belongs to both.
Leave restriction off only when the token must work across every workspace you can access (for example a personal automation script). CI jobs should usually set an explicit workspace via spanline auth workspace use and restrict the token.
MFA and enrollment
Organizations can require MFA. When enrollment is required:
- Product pages show a banner pointing to Account → Security.
- Token and session lists may be hidden until MFA is enrolled.
This is policy — not a token scope issue.
Roles (reminder)
| Role | Tokens & sessions |
|---|---|
| Workspace member | Mint personal tokens; manage own sessions |
| Org admin / owner | Same personal tokens; org settings are separate |
| Platform read-only | Can view tenants for support; cannot bypass org write rules |
End-user guides never describe silent admin bypass on org mutations.
Related guides
- Getting started — first CLI token
- Guides — UI walkthroughs
- Performance → Run tests — after CLI auth