Seismic User Management API Guide

Auth method: OAuth 2.0 (client credentials and authorization code flows)

Setup steps

1. Register an application in the Seismic Developer Portal to obtain a client_id and client_secret.
2. Request an access token via POST to https://auth.seismic.com/tenants/{tenant}/connect/token using client_credentials grant.
3. Include the returned Bearer token in the Authorization header of all API requests.
4. Tokens expire; implement refresh logic or re-request tokens using client credentials as needed.

Required scopes

List Users

• Method: GET
• URL: https://api.seismic.com/integration/v2/users
• Watch out for: Pagination parameters are page (1-based) and pageSize; omitting them returns the default page size.

Request example

GET /integration/v2/users?page=1&pageSize=25
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id": "abc-123", "email": "user@example.com", "firstName": "Jane", "lastName": "Doe", "isActive": true}
  ],
  "totalCount": 150,
  "page": 1,
  "pageSize": 25
}

Get User by ID

• Method: GET
• URL: https://api.seismic.com/integration/v2/users/{userId}
• Watch out for: Returns 404 if the userId does not exist in the tenant.

Request example

GET /integration/v2/users/abc-123
Authorization: Bearer {access_token}

Response example

{
  "id": "abc-123",
  "email": "user@example.com",
  "firstName": "Jane",
  "lastName": "Doe",
  "isActive": true,
  "role": "User"
}

Create User

• Method: POST
• URL: https://api.seismic.com/integration/v2/users
• Watch out for: Username must be unique; duplicate email/username returns a 409 Conflict.

Request example

POST /integration/v2/users
Authorization: Bearer {access_token}
Content-Type: application/json

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

Response example

{
  "id": "def-456",
  "email": "new@example.com",
  "firstName": "John",
  "lastName": "Smith",
  "isActive": true
}

Update User

• Method: PATCH
• URL: https://api.seismic.com/integration/v2/users/{userId}
• Watch out for: Only fields included in the request body are updated; omitted fields retain existing values.

Request example

PATCH /integration/v2/users/def-456
Authorization: Bearer {access_token}
Content-Type: application/json

{"title":"Senior Manager","department":"Sales"}

Response example

{
  "id": "def-456",
  "title": "Senior Manager",
  "department": "Sales"
}

Deactivate User

• Method: PATCH
• URL: https://api.seismic.com/integration/v2/users/{userId}
• Watch out for: Seismic does not expose a hard-delete user endpoint via the REST API; deactivation via isActive=false is the standard offboarding method.

Request example

PATCH /integration/v2/users/def-456
Authorization: Bearer {access_token}
Content-Type: application/json

{"isActive": false}

Response example

{
  "id": "def-456",
  "isActive": false
}

List Groups

• Method: GET
• URL: https://api.seismic.com/integration/v2/groups

Request example

GET /integration/v2/groups?page=1&pageSize=25
Authorization: Bearer {access_token}

Response example

{
  "data": [
    {"id": "grp-001", "name": "Sales Team", "memberCount": 12}
  ],
  "totalCount": 5
}

Add User to Group

• Method: POST
• URL: https://api.seismic.com/integration/v2/groups/{groupId}/members
• Watch out for: Adding a user already in the group may return 409; verify membership before calling.

Request example

POST /integration/v2/groups/grp-001/members
Authorization: Bearer {access_token}
Content-Type: application/json

{"userId": "def-456"}

Response example

{
  "groupId": "grp-001",
  "userId": "def-456",
  "addedAt": "2024-06-01T10:00:00Z"
}

Remove User from Group

• Method: DELETE
• URL: https://api.seismic.com/integration/v2/groups/{groupId}/members/{userId}
• Watch out for: Returns 404 if the user is not a member of the specified group.

Request example

DELETE /integration/v2/groups/grp-001/members/def-456
Authorization: Bearer {access_token}

Response example

HTTP 204 No Content

• Rate limits: Seismic's public developer documentation does not explicitly publish specific rate limit thresholds or tier-based limits as of the last known documentation review.

• Rate-limit headers: Unknown

• Retry-After header: Unknown

• Rate-limit notes: No explicit rate limit values, headers, or Retry-After behavior documented publicly. Contact Seismic support for current limits applicable to your tenant.

• Pagination method: offset

• Default page size: 25

• Max page size: 100

• Pagination pointer: page and pageSize

• Webhooks available: No

• Webhook notes: Seismic's public developer documentation does not describe outbound webhook support for user lifecycle events as of the last known documentation review.

• Alternative event strategy: Use SCIM provisioning with an IdP (e.g., Okta, Azure AD) to receive push-based user lifecycle events, or poll the REST API for user state changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://api.seismic.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} (deactivate/remove user), GET /Groups (list groups), POST /Groups (create group), PATCH /Groups/{id} (update group membership), DELETE /Groups/{id} (delete group)

Limitations:

• Requires SSO to be configured as a prerequisite before SCIM provisioning can be enabled.
• Available on Enterprise plan only; not available on lower tiers.
• SCIM token is generated within Seismic admin settings and must be provided as a Bearer token to the IdP connector.
• Hard delete behavior via SCIM DELETE may deactivate rather than permanently remove users depending on tenant configuration.
• IdP-specific connector configuration (e.g., Okta SCIM app, Azure AD enterprise app) is required; Seismic does not publish a generic connector.

Three integration scenarios are well-supported by the documented API surface.

First, onboarding: POST to /integration/v2/users with required fields, capture the returned id, then POST to /integration/v2/groups/{groupId}/members

check for 409 Conflict on both calls, as duplicate email/username and duplicate group membership both return 409.

Second, offboarding: PATCH /integration/v2/users/{userId} with {"isActive": false};

no hard-delete REST endpoint exists, so deactivation is the only supported path.

Follow up with DELETE /integration/v2/groups/{groupId}/members/{userId} for each group, since deactivation does not remove group membership.

Third, IdP-driven automation via SCIM: requires Enterprise plan and fully operational SSO before the SCIM token can be generated;

the Okta or Azure AD connector must target https://api.seismic.com/scim/v2 with the admin-generated Bearer token, not the OAuth token.

Webhooks for user lifecycle events are not documented;

polling or SCIM push are the only event-detection options.

Onboard a new sales user and assign to a group

1. Obtain an OAuth 2.0 access token via POST to https://auth.seismic.com/tenants/{tenant}/connect/token with client_credentials grant.
2. POST to /integration/v2/users with email, firstName, lastName, username, and role fields to create the user.
3. Capture the returned user id from the response.
4. POST to /integration/v2/groups/{groupId}/members with the new userId to add the user to the appropriate sales group.
5. Verify membership with GET /integration/v2/groups/{groupId}/members.

Watch out for: If the email already exists, the create call returns 409 Conflict. Check for existing users with GET /users?email={email} before creating.

Offboard a departing employee

1. Obtain a valid OAuth 2.0 access token.
2. Look up the user by email using GET /integration/v2/users with a filter or search parameter.
3. PATCH /integration/v2/users/{userId} with {"isActive": false} to deactivate the account.
4. Optionally, remove the user from all groups by calling DELETE /integration/v2/groups/{groupId}/members/{userId} for each group membership.

Watch out for: There is no hard-delete REST endpoint; deactivation is the supported method. Confirm with your Seismic admin whether deactivated users consume a license seat.

Set up SCIM auto-provisioning via Okta

1. Confirm the Seismic tenant is on the Enterprise plan and SSO is already configured.
2. In Seismic admin settings, navigate to the SCIM provisioning section and generate a SCIM Bearer token.
3. In Okta, add the Seismic application from the Okta Integration Network and enable SCIM provisioning.
4. Enter the Seismic SCIM base URL (https://api.seismic.com/scim/v2) and the generated Bearer token into the Okta SCIM connector settings.
5. Enable the desired provisioning features in Okta (Create Users, Update User Attributes, Deactivate Users, Push Groups).
6. Assign users or groups in Okta to trigger initial provisioning to Seismic.

Watch out for: SSO must be fully operational before SCIM is enabled. Enabling SCIM without SSO configured will result in provisioning failures. The SCIM token is separate from the REST API OAuth token.

The most consequential caveat is the dual-token architecture: the REST API OAuth token and the SCIM Bearer token are issued through entirely different flows, and using the wrong token against either endpoint will produce authentication failures that are easy to misdiagnose.

Rate limits are not publicly documented - no thresholds, no rate-limit headers, and no Retry-After behavior are specified - so any bulk operation or high-frequency polling loop must be validated against a non-production tenant before running in production. OAuth access tokens have a finite TTL;

without token caching and renewal logic, long-running workflows will hit 401 errors mid-execution.

Finally, the identity graph built from the REST API reflects role and group membership but does not expose Profile assignments, which are the actual determinant of content visibility in Seismic - automations that only sync role and group state may leave users in a technically active but functionally misconfigured state.