Sentry User Management API Guide

Auth method: Bearer token (User Auth Token or Internal Integration Token)

Setup steps

1. Navigate to Settings > Account > API > Auth Tokens in the Sentry UI.
2. Click 'Create New Token' and select the required scopes (e.g., member:read, member:write, org:read).
3. Copy the generated token; it is shown only once.
4. Pass the token in the Authorization header: 'Authorization: Bearer '.
5. For organization-level automation, create an Internal Integration under Settings > Developer Settings > New Internal Integration and assign scopes there.

Required scopes

List organization members

• Method: GET
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/
• Watch out for: Returns cursor-paginated results. Pending (unaccepted) invites are included in the list.

Request example

GET /api/0/organizations/my-org/members/
Authorization: Bearer <token>

Response example

[
  {
    "id": "123",
    "email": "alice@example.com",
    "role": "member",
    "pending": false,
    "user": {"id": "456", "name": "Alice"}
  }
]

Get a single organization member

• Method: GET
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/{member_id}/
• Watch out for: Use the member ID (not the global user ID) as the path parameter.

Request example

GET /api/0/organizations/my-org/members/123/
Authorization: Bearer <token>

Response example

{
  "id": "123",
  "email": "alice@example.com",
  "role": "member",
  "teamRoles": [{"teamSlug": "backend", "role": "contributor"}],
  "flags": {"sso:linked": true}
}

Invite a new member

• Method: POST
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/
• Watch out for: Sends an invitation email. The member is pending until they accept. Requires member:write scope. On SSO-enforced orgs, the user must log in via SSO to activate.

Request example

POST /api/0/organizations/my-org/members/
Authorization: Bearer <token>
Content-Type: application/json

{"email":"bob@example.com","role":"member","teams":["backend"]}

Response example

{
  "id": "789",
  "email": "bob@example.com",
  "role": "member",
  "pending": true
}

Update a member's role or teams

• Method: PUT
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/{member_id}/
• Watch out for: Cannot downgrade the last owner. Role changes take effect immediately.

Request example

PUT /api/0/organizations/my-org/members/123/
Authorization: Bearer <token>
Content-Type: application/json

{"role":"admin","teamRoles":[{"teamSlug":"backend","role":"admin"}]}

Response example

{
  "id": "123",
  "role": "admin",
  "teamRoles": [{"teamSlug": "backend", "role": "admin"}]
}

Remove a member from the organization

• Method: DELETE
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/{member_id}/
• Watch out for: Irreversible via API. The user loses access immediately. Cannot delete the sole owner.

Request example

DELETE /api/0/organizations/my-org/members/123/
Authorization: Bearer <token>

Response example

HTTP 204 No Content

List teams

• Method: GET
• URL: https://sentry.io/api/0/organizations/{organization_slug}/teams/
• Watch out for: Cursor-paginated. Use team slug (not ID) in subsequent team-member endpoints.

Request example

GET /api/0/organizations/my-org/teams/
Authorization: Bearer <token>

Response example

[
  {"id": "1", "slug": "backend", "name": "Backend", "memberCount": 5}
]

Add member to a team

• Method: POST
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/{member_id}/teams/{team_slug}/
• Watch out for: Uses member_id (org-scoped), not global user ID. Returns updated member object.

Request example

POST /api/0/organizations/my-org/members/123/teams/backend/
Authorization: Bearer <token>

Response example

{
  "id": "123",
  "teams": ["backend"]
}

Remove member from a team

• Method: DELETE
• URL: https://sentry.io/api/0/organizations/{organization_slug}/members/{member_id}/teams/{team_slug}/
• Watch out for: Returns 200 (not 204) with updated member object on success.

Request example

DELETE /api/0/organizations/my-org/members/123/teams/backend/
Authorization: Bearer <token>

Response example

HTTP 200 OK
{"id": "123", "teams": []}

• Rate limits: Sentry enforces per-token and per-organization rate limits. Limits vary by endpoint category. The API returns HTTP 429 when limits are exceeded.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: Sentry returns X-Sentry-Rate-Limit and Retry-After headers on 429 responses. Exact numeric limits are not publicly documented per plan tier. Respect Retry-After before retrying.
• Pagination method: cursor
• Default page size: 100
• Max page size: 100
• Pagination pointer: cursor

• Webhooks available: Yes
• Webhook notes: Sentry supports webhooks via Internal Integrations and the Sentry integration platform. Webhooks fire on issue, error, and workflow events but do not natively emit user/member lifecycle events (invite accepted, member removed).
• Alternative event strategy: Poll GET /organizations/{org_slug}/members/ on a schedule to detect membership changes. For provisioning events, use SCIM with an IdP that supports push groups.
• Webhook events: issue.created, issue.resolved, issue.assigned, issue.ignored, error.created, comment.created, comment.updated, comment.deleted, metric_alert.open, metric_alert.resolved

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Business or Enterprise (SAML SSO must be configured first)

• Endpoint: https://sentry.io/scim/v2/

• Supported operations: GET /Users - list provisioned users, POST /Users - provision a new user, GET /Users/{id} - retrieve a user, PATCH /Users/{id} - update user attributes or deactivate (active=false), DELETE /Users/{id} - deprovision a user, GET /Groups - list teams as SCIM groups, POST /Groups - create a team, GET /Groups/{id} - retrieve a team, PATCH /Groups/{id} - add/remove members from a team, DELETE /Groups/{id} - delete a team

Limitations:

• SCIM is only available on Business and Enterprise plans.
• SAML SSO must be fully configured before enabling SCIM.
• Not available on Trial plans.
• SCIM token is a separate token generated under Settings > Auth > SCIM - not a standard API auth token.
• PATCH /Users supports only active attribute for deprovisioning; full attribute updates are limited.
• JIT (Just-In-Time) provisioning via SSO creates users on first login independently of SCIM.
• SCIM Groups map to Sentry Teams; group display names must match existing team slugs or a new team is created.
• Deprovisioning sets active=false but does not immediately delete the member record in all IdP flows.

Three automation scenarios cover the majority of lifecycle operations.

Bulk invitations require member:write scope; POST to /api/0/organizations/{org_slug}/members/ with role and teams array per user, then poll the returned member_id for pending status - on SSO-enforced orgs, acceptance happens via SSO login, not the email link. Role promotion (e.

g. , Member → Admin) uses PUT to /api/0/organizations/{org_slug}/members/{member_id}/ with a lowercase role string; tokens from callers without owner or manager org role receive a 403.

Deprovisioning via SCIM is the preferred offboarding path: the IdP sends PATCH /scim/v2/Users/{id} with active=false, revoking access immediately - but if the user was JIT-provisioned via SSO without a prior SCIM push, the SCIM user ID may not exist and the fallback is DELETE /api/0/organizations/{org_slug}/members/{member_id}/ via REST.

Bulk invite new team members and assign to a team

1. Authenticate with a token scoped to member:write and team:read.
2. GET /api/0/organizations/{org_slug}/teams/ to retrieve the target team slug.
3. For each user email, POST /api/0/organizations/{org_slug}/members/ with {email, role: 'member', teams: [team_slug]}.
4. Store the returned member id for each invite.
5. Poll GET /api/0/organizations/{org_slug}/members/{member_id}/ to check pending status until accepted.

Watch out for: Each invite sends an email. On SSO-enforced orgs, users must accept via SSO login, not the email link directly.

Deprovision a departing employee via SCIM

1. Ensure SCIM is configured in the IdP (Okta/Entra) pointing to https://sentry.io/scim/v2/ with the SCIM Bearer token.
2. In the IdP, remove the user from the Sentry application assignment.
3. The IdP sends PATCH /scim/v2/Users/{id} with {op: replace, path: active, value: false}.
4. Sentry deactivates the member, revoking access immediately.
5. Verify by calling GET /api/0/organizations/{org_slug}/members/ and confirming the member no longer appears or is marked inactive.

Watch out for: If JIT provisioning was used (user logged in via SSO without SCIM push), the SCIM user ID may not exist; fall back to DELETE /api/0/organizations/{org_slug}/members/{member_id}/ via REST API.

Promote a member to admin role

1. Authenticate with a token scoped to member:write and org:admin.
2. GET /api/0/organizations/{org_slug}/members/ to find the target member's id.
3. PUT /api/0/organizations/{org_slug}/members/{member_id}/ with body {"role": "admin"}.
4. Confirm the response returns role: 'admin'.

Watch out for: Only users with 'owner' or 'manager' role can promote others to 'admin'. Tokens from users without sufficient org role will receive a 403.

Several non-obvious behaviors create integration risk. Member IDs are organization-scoped integers distinct from the global user.id nested in the user object - conflating them breaks lookups and corrupts identity graph joins between Sentry membership records and canonical directory profiles.

Pagination uses Link header cursor values, not page or offset parameters; implementations that ignore the Link: rel="next" header will silently truncate results on large orgs. Rate limits return HTTP 429 with Retry-After and X-Sentry-Rate-Limit headers, but exact per-plan numeric thresholds are not publicly documented - exponential backoff is required.

Webhooks do not emit member lifecycle events (invite accepted, member removed), so membership state must be derived by polling GET /organizations/{org_slug}/members/ on a schedule or by consuming SCIM push events from the IdP.

Finally, the Owner role is fully excluded from SCIM management; any workflow that assumes SCIM covers all role transitions will silently leave Owner assignments unmanaged.