Sigma Computing User Management API Guide

Auth method: OAuth 2.0 Client Credentials (Bearer token)

Setup steps

1. Navigate to Administration > Developer Access in Sigma.
2. Create a new API client to obtain a Client ID and Client Secret.
3. POST to https://aws-api.sigmacomputing.com/v2/auth/token with grant_type=client_credentials, client_id, and client_secret in the request body.
4. Extract the access_token from the response and include it as 'Authorization: Bearer ' on all subsequent API requests.
5. Tokens expire; re-authenticate using the same flow when the token is no longer valid.

Required scopes

List Members

• Method: GET
• URL: https://aws-api.sigmacomputing.com/v2/members
• Watch out for: Use the nextPage cursor value as page_token in subsequent requests to paginate through all members.

Request example

GET /v2/members?limit=50 HTTP/1.1
Authorization: Bearer <token>

Response example

{
  "entries": [{"memberId":"abc123","email":"user@example.com","memberType":"Creator"}],
  "nextPage": "<cursor_token>",
  "total": 120
}

Get Member

• Method: GET
• URL: https://aws-api.sigmacomputing.com/v2/members/{memberId}
• Watch out for: memberId is Sigma's internal UUID, not the user's email.

Request example

GET /v2/members/abc123 HTTP/1.1
Authorization: Bearer <token>

Response example

{
  "memberId": "abc123",
  "email": "user@example.com",
  "firstName": "Jane",
  "lastName": "Doe",
  "memberType": "Creator"
}

Create Member

• Method: POST
• URL: https://aws-api.sigmacomputing.com/v2/members
• Watch out for: memberType must match a license type available in the org; invalid values return a 400 error.

Request example

POST /v2/members HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"email":"new@example.com","memberType":"Viewer","firstName":"John","lastName":"Smith"}

Response example

{
  "memberId": "xyz789",
  "email": "new@example.com",
  "memberType": "Viewer",
  "createdAt": "2024-01-15T10:00:00Z"
}

Update Member

• Method: PATCH
• URL: https://aws-api.sigmacomputing.com/v2/members/{memberId}
• Watch out for: Only fields included in the PATCH body are updated; omitted fields retain their current values.

Request example

PATCH /v2/members/abc123 HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"memberType":"Creator"}

Response example

{
  "memberId": "abc123",
  "email": "user@example.com",
  "memberType": "Creator",
  "updatedAt": "2024-06-01T12:00:00Z"
}

Delete Member

• Method: DELETE
• URL: https://aws-api.sigmacomputing.com/v2/members/{memberId}
• Watch out for: Deletion is permanent. Ensure content owned by the member is reassigned before deletion to avoid orphaned assets.

Request example

DELETE /v2/members/abc123 HTTP/1.1
Authorization: Bearer <token>

Response example

HTTP/1.1 204 No Content

List Teams

• Method: GET
• URL: https://aws-api.sigmacomputing.com/v2/teams
• Watch out for: Teams are the primary mechanism for group-based permission management in Sigma.

Request example

GET /v2/teams HTTP/1.1
Authorization: Bearer <token>

Response example

{
  "entries": [{"teamId":"team001","name":"Analytics"}],
  "nextPage": null
}

Add Member to Team

• Method: POST
• URL: https://aws-api.sigmacomputing.com/v2/teams/{teamId}/members
• Watch out for: Member must already exist in the org before being added to a team.

Request example

POST /v2/teams/team001/members HTTP/1.1
Authorization: Bearer <token>
Content-Type: application/json

{"memberId":"abc123"}

Response example

HTTP/1.1 200 OK
{
  "teamId": "team001",
  "memberId": "abc123"
}

Get Auth Token

• Method: POST
• URL: https://aws-api.sigmacomputing.com/v2/auth/token
• Watch out for: Tokens expire (expires_in seconds). Implement token refresh logic; do not hardcode tokens.

Request example

POST /v2/auth/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials&client_id=<id>&client_secret=<secret>

Response example

{
  "access_token": "eyJ...",
  "token_type": "Bearer",
  "expires_in": 3600
}

• Rate limits: Sigma does not publicly document specific rate limit thresholds or per-plan tiers in its official API docs as of the policy date.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No explicit rate limit values, headers, or Retry-After behavior documented in official sources. Contact Sigma support for current limits.

• Pagination method: token

• Default page size: 50

• Max page size: 1000

• Pagination pointer: page_token (next page cursor returned in response as nextPage)

• Webhooks available: No

• Webhook notes: Sigma does not document outbound webhooks for user or member lifecycle events in its official API or help documentation as of the policy date.

• Alternative event strategy: Poll the GET /v2/members endpoint periodically to detect membership changes, or use SCIM provisioning with an IdP for event-driven user lifecycle management.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://aws-api.sigmacomputing.com/scim/v2

• Supported operations: GET /Users (list users), GET /Users/{id} (get user), POST /Users (create user), PUT /Users/{id} (replace user), PATCH /Users/{id} (update user), DELETE /Users/{id} (deprovision user), GET /Groups (list groups/teams), POST /Groups (create group), PATCH /Groups/{id} (update group membership), DELETE /Groups/{id} (delete group)

Limitations:

• Requires SSO (SAML) to be configured before SCIM can be enabled.
• Only available on the Enterprise plan.
• SCIM bearer token is generated within Sigma Admin settings and must be provided to the IdP.
• SCIM Groups map to Sigma Teams; group display names must be unique.
• Deprovisioning via SCIM deactivates the user but may not immediately free the license seat depending on configuration.

Three primary automation scenarios are well-supported by the API.

First, bulk onboarding: authenticate, POST /v2/members for each user with email, firstName, lastName, and memberType, capture the returned memberId, then POST to /v2/teams/{teamId}/members to assign department-based team membership.

Second, employee offboarding: resolve memberId via GET /v2/members filtered by email, handle content reassignment in the UI (no API endpoint exists for this), then call DELETE /v2/members/{memberId}.

Third, IdP-driven lifecycle management via SCIM 2.0 at https://aws-api.sigmacomputing.com/scim/v2 - requires Enterprise plan and active SAML SSO;

the SCIM bearer token is a static credential generated in Sigma Admin, separate from the OAuth token, and must be rotated manually if compromised.

SCIM Groups map to Sigma Teams;

group display names must be unique.

Sigma does not document outbound webhooks for member lifecycle events;

use periodic polling of GET /v2/members or SCIM with an IdP as the event-driven alternative.

Bulk onboard new employees via REST API

1. Authenticate: POST /v2/auth/token with client_id and client_secret to obtain a Bearer token.
2. For each new employee, POST /v2/members with email, firstName, lastName, and memberType.
3. Capture the returned memberId for each created member.
4. POST /v2/teams/{teamId}/members for each memberId to assign team membership based on department.

Watch out for: Validate that the memberType value matches an available license in the org before bulk creation to avoid 400 errors mid-batch.

Deprovision a departing employee

1. Authenticate to obtain a Bearer token.
2. GET /v2/members?email=user@example.com or list and filter to find the target memberId.
3. Optionally reassign owned content via Sigma Admin UI before deletion (no API endpoint for content reassignment documented).
4. DELETE /v2/members/{memberId} to remove the member from the organization.

Watch out for: There is no API endpoint to bulk-reassign content owned by the deleted member; handle content ownership in the Sigma UI prior to deletion.

Set up SCIM provisioning with an IdP (e.g., Okta)

1. Confirm the Sigma org is on the Enterprise plan and has SAML SSO configured and active.
2. In Sigma Administration > Authentication, enable SCIM and copy the generated SCIM bearer token.
3. In the IdP (e.g., Okta), configure a SCIM 2.0 connector with base URL https://aws-api.sigmacomputing.com/scim/v2 and the bearer token.
4. Map IdP user attributes to SCIM User schema fields (userName → email, givenName, familyName).
5. Assign users and groups in the IdP; the IdP will push provisioning events to Sigma's SCIM endpoint automatically.

Watch out for: The SCIM bearer token is separate from the REST API OAuth token; it is a static token generated in Sigma Admin and must be rotated manually if compromised.

The Sigma Members API integrates cleanly into an identity graph where Sigma seat assignments need to stay in sync with authoritative HR or IdP data - memberId, memberType, teams, createdAt, and updatedAt are all available on the member object and sufficient for building a consistent user state snapshot.

The key operational traps: pagination is cursor-based (never numeric offset), memberType values are org-specific and must be validated before batch writes, and the API client holds org-wide admin access with no scope granularity, so credential hygiene is critical. Rate limits are not publicly documented; contact Sigma support before designing high-frequency polling loops.

SCIM and the REST API use separate authentication mechanisms and should not be treated as interchangeable in the same provisioning pipeline.