Team and roles
The two-tier access model — workspace roles and per-application roles — and why granting workspace admin is almost always more than someone needs.
Access in Throttle has two tiers, and people are routinely given more than they need because only one of the tiers is obvious. A workspace role says who you are across the company; an application role says what you can do in one storefront.
Workspace roles
| Role | What it means |
|---|---|
owner | The creator. Exactly one per workspace. Owns billing, transfer, and deletion |
workspace_admin | Implicit admin on every application, including ones created later |
member | No application access by default — access is granted per application |
Application roles
A member gets explicit roles on the applications they should reach:
| Role | Typically |
|---|---|
admin | Full control of that application |
developer | Integration work — keys, webhooks, configuration |
finance | Invoices, receivables, payments |
viewer | Read-only |
Owners and workspace admins do not need application roles. They already have admin everywhere, which is exactly why the tier is easy to over-grant.
workspace_adminis not “admin of the application they work on”. It is admin of every application in the workspace, including every application you create in future. Someone who runs one brand’s storefront should be amemberwith theadminrole on that application — otherwise they silently gain full access to the next brand you launch.
The pattern that ages well: owner for whoever owns the company relationship, workspace_admin for the one or two people who genuinely operate everything, and member plus explicit application roles for everyone else.
Inviting people
An invite is sent to an email address and carries the roles it will grant. A few properties worth knowing:
- The invite expires after 7 days.
- Resending rotates the token, so an old link stops working.
- Revoking invalidates it immediately.
- The email on the account must match the email the invite was sent to. Someone cannot accept an invite for
finance@while signed in aspersonal@.
That last rule is strict on purpose — it stops an invite forwarded around the office from attaching to whoever happened to click it.
Environment scope
Team access can be narrowed by environment as well as by application, so a contractor can be given a sandbox without production. Combine this with a viewer role when someone needs to see how things are set up without the ability to touch live data.
Permissions are checked, not assumed
Every action maps to a named permission, and access is granted when either the caller’s workspace role or their application role satisfies it. There is no place where a role string is compared directly, which means the two tiers cannot drift apart — a permission either lists a role or it does not.
API keys are outside this model entirely. A key is gated purely by the scopes it holds and carries no role at all, so removing someone from the team does not revoke a key they created. Rotate keys when someone leaves. See API keys and environments.
Last updated August 9, 2026