Snyk User Management API Guide

Auth method: API Token (Bearer token in Authorization header). Personal API tokens or service account tokens are supported. No OAuth 2.0 flow is documented for the REST API.

Setup steps

1. Log in to Snyk and navigate to Account Settings → General → Auth Token.
2. Copy the personal API token, or create a service account token under Group/Org Settings → Service Accounts.
3. Pass the token as a Bearer token: Authorization: token <YOUR_TOKEN> in all API requests.
4. Include the required API version query parameter: ?version=2024-10-15 (use latest stable version from apidocs.snyk.io).

Required scopes

Get authenticated user (self)

• Method: GET
• URL: https://api.snyk.io/rest/self?version=2024-10-15
• Watch out for: Returns the token owner's profile only; cannot retrieve arbitrary users by ID via this endpoint.

Request example

GET /rest/self?version=2024-10-15
Authorization: token <TOKEN>

Response example

{
  "data": {
    "id": "uuid-user",
    "type": "user",
    "attributes": {
      "name": "Jane Doe",
      "email": "jane@example.com",
      "username": "jane.doe"
    }
  }
}

List organization members

• Method: GET
• URL: https://api.snyk.io/rest/orgs/{org_id}/members?version=2024-10-15
• Watch out for: Requires Org Admin or Group Admin token. Paginated via cursor; iterate links.next until absent.

Request example

GET /rest/orgs/ORG_ID/members?version=2024-10-15&limit=10
Authorization: token <TOKEN>

Response example

{
  "data": [
    {
      "id": "uuid-membership",
      "type": "org_membership",
      "attributes": {
        "role": "collaborator",
        "email": "jane@example.com"
      }
    }
  ],
  "links": {"next": "...cursor..."}
}

Invite user to organization

• Method: POST
• URL: https://api.snyk.io/rest/orgs/{org_id}/invites?version=2024-10-15
• Watch out for: User must accept the email invite before they appear as an active member. Inviting an already-active member returns a 409 conflict.

Request example

POST /rest/orgs/ORG_ID/invites?version=2024-10-15
Content-Type: application/vnd.api+json
{
  "data": {
    "type": "org_invitation",
    "attributes": {"email": "new@example.com", "role": "collaborator"}
  }
}

Response example

{
  "data": {
    "id": "uuid-invite",
    "type": "org_invitation",
    "attributes": {
      "email": "new@example.com",
      "status": "pending"
    }
  }
}

Update organization member role

• Method: PATCH
• URL: https://api.snyk.io/rest/orgs/{org_id}/members/{membership_id}?version=2024-10-15
• Watch out for: Custom role IDs (Enterprise) must be used instead of string names when assigning custom roles.

Request example

PATCH /rest/orgs/ORG_ID/members/MEMBERSHIP_ID?version=2024-10-15
Content-Type: application/vnd.api+json
{
  "data": {
    "type": "org_membership",
    "attributes": {"role": "admin"}
  }
}

Response example

{
  "data": {
    "id": "MEMBERSHIP_ID",
    "type": "org_membership",
    "attributes": {"role": "admin"}
  }
}

Remove user from organization

• Method: DELETE
• URL: https://api.snyk.io/rest/orgs/{org_id}/members/{membership_id}?version=2024-10-15
• Watch out for: Deletes org membership only; does not delete the Snyk user account or remove them from other orgs.

Request example

DELETE /rest/orgs/ORG_ID/members/MEMBERSHIP_ID?version=2024-10-15
Authorization: token <TOKEN>

Response example

HTTP 204 No Content

List group members

• Method: GET
• URL: https://api.snyk.io/rest/groups/{group_id}/members?version=2024-10-15
• Watch out for: Requires Group Admin token. Enterprise plan only. Group-level roles are separate from org-level roles.

Request example

GET /rest/groups/GROUP_ID/members?version=2024-10-15&limit=100
Authorization: token <TOKEN>

Response example

{
  "data": [
    {
      "id": "uuid-group-membership",
      "type": "group_membership",
      "attributes": {
        "role": "group_viewer",
        "email": "jane@example.com"
      }
    }
  ]
}

Update group member role

• Method: PATCH
• URL: https://api.snyk.io/rest/groups/{group_id}/members/{membership_id}?version=2024-10-15
• Watch out for: Enterprise only. Group Admin token required.

Request example

PATCH /rest/groups/GROUP_ID/members/MEMBERSHIP_ID?version=2024-10-15
Content-Type: application/vnd.api+json
{
  "data": {
    "type": "group_membership",
    "attributes": {"role": "group_admin"}
  }
}

Response example

{
  "data": {
    "id": "MEMBERSHIP_ID",
    "type": "group_membership",
    "attributes": {"role": "group_admin"}
  }
}

List pending org invitations

• Method: GET
• URL: https://api.snyk.io/rest/orgs/{org_id}/invites?version=2024-10-15
• Watch out for: Only returns invitations not yet accepted. Accepted invites appear in /members instead.

Request example

GET /rest/orgs/ORG_ID/invites?version=2024-10-15
Authorization: token <TOKEN>

Response example

{
  "data": [
    {
      "id": "uuid-invite",
      "type": "org_invitation",
      "attributes": {
        "email": "pending@example.com",
        "status": "pending"
      }
    }
  ]
}

• Rate limits: Snyk enforces rate limits per API token. The REST API returns 429 responses when limits are exceeded. Limits vary by plan and endpoint category.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: On 429, respect the Retry-After header. Snyk docs recommend exponential backoff. Rate limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) are returned on REST API responses.
• Pagination method: cursor
• Default page size: 10
• Max page size: 100
• Pagination pointer: starting_after / ending_before (cursor tokens returned in links.next and links.prev response fields)

• Webhooks available: Yes
• Webhook notes: Snyk supports webhooks for project-level events (e.g., new vulnerabilities, test results). There are no dedicated user-lifecycle webhook events (user added, removed, role changed) documented in the official API.
• Alternative event strategy: Poll the /orgs/{org_id}/members and /orgs/{org_id}/invites endpoints on a schedule to detect membership changes.
• Webhook events: ping, project.snapshot.created (new test result / vulnerability found)

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• Snyk does not expose a native SCIM 2.0 endpoint.
• Enterprise SSO (Okta, Entra ID, Google Workspace, OneLogin) can auto-provision users on first login via custom attribute mapping, but this is not SCIM.
• Deprovisioning must be handled via the REST API (DELETE membership) or by disabling the user in the IdP (which blocks SSO login but does not remove the Snyk account).
• Custom provisioning mapping is available for Enterprise plans with SSO configured.

Three scenarios cover the majority of programmatic identity graph use cases against Snyk. For bulk provisioning, POST to /rest/orgs/{org_id}/invites per user - users must accept the email invite before they appear in /members; there is no force-add path without SSO auto-provisioning.

For offboarding, a Group Admin service account token is required to enumerate all orgs via /rest/groups/{group_id}/members, then DELETE each /rest/orgs/{org_id}/members/{membership_id} individually - this removes org membership only, not the Snyk account, and the user retains direct (non-SSO) login unless the IdP also blocks them.

For cross-org auditing, paginate /rest/orgs/{org_id}/members for every org in the group (follow links. next cursor; default page size 10, max 100), then cross-reference with /rest/groups/{group_id}/members for group-level role assignments.

On 429 responses, respect the Retry-After header and apply exponential backoff - rate limits are not publicly documented per tier for Enterprise.

Bulk-provision users to a new Snyk organization

1. Create a service account token with Org Admin scope for the target org.
2. For each user email, POST to /rest/orgs/{org_id}/invites with the desired role (collaborator or admin).
3. Poll GET /rest/orgs/{org_id}/invites to monitor pending invitations.
4. After users accept invites, verify membership via GET /rest/orgs/{org_id}/members.
5. For Enterprise: configure SSO so future users are auto-provisioned on first login without manual invites.

Watch out for: Users must accept email invitations before they appear as active members. There is no way to force-add a user without an invite flow unless SSO auto-provisioning is configured.

Offboard a departing employee from all Snyk orgs

1. Use a Group Admin service account token (Enterprise) or iterate each org individually.
2. GET /rest/groups/{group_id}/members to find the user's group membership ID, then DELETE it.
3. For each org, GET /rest/orgs/{org_id}/members, filter by the user's email to find membership_id.
4. DELETE /rest/orgs/{org_id}/members/{membership_id} for each org.
5. Disable the user in the IdP to block future SSO logins.
6. Revoke or rotate any personal API tokens the user may have created (manual step in Snyk UI or via service account audit).

Watch out for: Removing org/group memberships does not delete the Snyk account. The user can still log in directly (non-SSO) unless their account is fully deactivated. There is no DELETE /users/{id} endpoint in the public REST API.

Audit all org members and their roles across a Snyk group

1. Authenticate with a Group Admin service account token.
2. GET /rest/groups/{group_id}/orgs to retrieve all org IDs in the group.
3. For each org_id, paginate GET /rest/orgs/{org_id}/members (follow links.next until absent).
4. Aggregate results into a report mapping email → org → role.
5. Cross-reference with GET /rest/groups/{group_id}/members for group-level role assignments.

Watch out for: Cursor pagination must be followed correctly - do not cache or reuse cursors across sessions. Large groups with many orgs may approach rate limits; implement exponential backoff on 429 responses.

The most consequential API caveat is the absence of a DELETE /users/{id} endpoint: there is no way to fully deactivate a Snyk account via the public REST API. Deleting an org membership removes access to that org's projects and data, but the user account persists and remains capable of direct login.

Snyk also has no native SCIM 2.0 endpoint - Enterprise SSO auto-provisioning via custom attribute mapping is not SCIM and does not support SCIM deprovisioning semantics. Custom role IDs (Enterprise) must be passed as UUIDs in PATCH requests, not as human-readable strings; using a custom role ID against a non-Enterprise org returns a 403.

Cursor pagination is session-scoped - do not reuse or cache cursor tokens across requests, and do not apply offset arithmetic to links.next values.