Which part? Which one?
Account Settings → Auth Tokens, and Organization → Membership
Description
Two related articles don't make it possible to figure out from the docs how to grant API access scoped to a subset of an organization's projects:
https://docs.sentry.io/account/auth-tokens/
https://docs.sentry.io/organization/membership/
Specific gaps:
The Auth Tokens article describes the three token types but does not explicitly state that Org Auth Tokens and Internal Integration tokens grant access to all projects in the organization regardless of teams (i.e. they cannot be scoped to a subset of projects). It also does not surface the fact that Personal Auth Tokens combined with team membership are the only native way to scope an API token to a subset of projects — that capability is currently framed only as a limitation ("a personal token's maximum scope is all the scopes that the user has access to").
The Membership article's Open Membership section does not state that Open Membership only restricts team/project access for Members and Admins. Managers and Owners always have access to all teams and projects regardless of this setting (because both roles are global). A reader who disables Open Membership to lock a user down to specific teams can be silently surprised by this when the user holds the Manager or Owner role.
Suggested Solution
In the Auth Tokens article (source):
In the Organization Tokens and Internal Integrations sections, add an explicit line stating that these tokens grant access to all projects in the organization regardless of team membership, and cannot be scoped to a subset of projects.
Add a short subsection under When Should I Use Which? titled something like "Scoping a Token to a Subset of Projects", explaining that Personal Tokens combined with team membership are the supported way to achieve this, with a note that the underlying user's org role must be Member or Admin (Manager and Owner bypass team-based project scoping). Cross-link to the Membership article.
In the Organization and User Management article (source):
Add a short callout in the Open Membership section: "Open Membership controls team access for Members and Admins only. Managers and Owners always have access to all teams and projects regardless of this setting."
Which part? Which one?
Account Settings → Auth Tokens, and Organization → Membership
Description
Two related articles don't make it possible to figure out from the docs how to grant API access scoped to a subset of an organization's projects:
https://docs.sentry.io/account/auth-tokens/
https://docs.sentry.io/organization/membership/
Specific gaps:
The Auth Tokens article describes the three token types but does not explicitly state that Org Auth Tokens and Internal Integration tokens grant access to all projects in the organization regardless of teams (i.e. they cannot be scoped to a subset of projects). It also does not surface the fact that Personal Auth Tokens combined with team membership are the only native way to scope an API token to a subset of projects — that capability is currently framed only as a limitation ("a personal token's maximum scope is all the scopes that the user has access to").
The Membership article's Open Membership section does not state that Open Membership only restricts team/project access for Members and Admins. Managers and Owners always have access to all teams and projects regardless of this setting (because both roles are global). A reader who disables Open Membership to lock a user down to specific teams can be silently surprised by this when the user holds the Manager or Owner role.
Suggested Solution
In the Auth Tokens article (source):
In the Organization Tokens and Internal Integrations sections, add an explicit line stating that these tokens grant access to all projects in the organization regardless of team membership, and cannot be scoped to a subset of projects.
Add a short subsection under When Should I Use Which? titled something like "Scoping a Token to a Subset of Projects", explaining that Personal Tokens combined with team membership are the supported way to achieve this, with a note that the underlying user's org role must be Member or Admin (Manager and Owner bypass team-based project scoping). Cross-link to the Membership article.
In the Organization and User Management article (source):
Add a short callout in the Open Membership section: "Open Membership controls team access for Members and Admins only. Managers and Owners always have access to all teams and projects regardless of this setting."