Jasper User Management API Guide

Auth method: API Key (Bearer token) for content API; SCIM uses a separate long-lived bearer token generated in Jasper admin settings

Setup steps

1. For content API: Navigate to Jasper Settings → API → Generate API Key; pass as Authorization: Bearer header.
2. For SCIM: Navigate to Jasper Admin → Security → SCIM Provisioning; enable SCIM and copy the generated SCIM bearer token.
3. Configure your IdP (Okta or Entra ID) with the SCIM base URL and bearer token.
4. Assign users/groups in the IdP to trigger provisioning to Jasper.

List Users

• Method: GET
• URL: https://api.jasper.ai/scim/v2/Users
• Watch out for: Filter support may be limited; test filter expressions against your Jasper instance before relying on them in automation.

Request example

GET /scim/v2/Users?filter=userName eq "user@example.com"
Authorization: Bearer <scim_token>
Content-Type: application/scim+json

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 1,
  "Resources": [{
    "id": "abc123",
    "userName": "user@example.com",
    "active": true
  }]
}

Get User

• Method: GET
• URL: https://api.jasper.ai/scim/v2/Users/{id}
• Watch out for: SCIM ID is Jasper-internal; store it after provisioning for subsequent operations.

Request example

GET /scim/v2/Users/abc123
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "id": "abc123",
  "userName": "user@example.com",
  "active": true,
  "name": {"givenName": "Jane", "familyName": "Doe"}
}

Create User

• Method: POST
• URL: https://api.jasper.ai/scim/v2/Users
• Watch out for: User receives an invitation email from Jasper upon provisioning; seat consumption begins immediately.

Request example

POST /scim/v2/Users
Authorization: Bearer <scim_token>
Content-Type: application/scim+json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
  "userName": "newuser@example.com",
  "name": {"givenName": "John", "familyName": "Smith"},
  "active": true
}

Response example

{
  "id": "xyz789",
  "userName": "newuser@example.com",
  "active": true
}

Update User (partial)

• Method: PATCH
• URL: https://api.jasper.ai/scim/v2/Users/{id}
• Watch out for: Setting active=false deactivates the user but may not immediately free the seat depending on billing cycle.

Request example

PATCH /scim/v2/Users/xyz789
Authorization: Bearer <scim_token>
Content-Type: application/scim+json
{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
  "Operations": [{"op": "replace", "path": "active", "value": false}]
}

Response example

{
  "id": "xyz789",
  "userName": "newuser@example.com",
  "active": false
}

Delete User

• Method: DELETE
• URL: https://api.jasper.ai/scim/v2/Users/{id}
• Watch out for: Deletion is typically handled via active=false (deprovision) in IdP-driven flows; hard DELETE behavior should be verified with Jasper support.

Request example

DELETE /scim/v2/Users/xyz789
Authorization: Bearer <scim_token>

Response example

HTTP 204 No Content

List Groups

• Method: GET
• URL: https://api.jasper.ai/scim/v2/Groups
• Watch out for: Groups in Jasper map to teams/workspaces; group provisioning availability depends on plan and IdP configuration.

Request example

GET /scim/v2/Groups
Authorization: Bearer <scim_token>

Response example

{
  "schemas": ["urn:ietf:params:scim:api:messages:2.0:ListResponse"],
  "totalResults": 2,
  "Resources": [{"id": "grp1", "displayName": "Marketing"}]
}

Create Group

• Method: POST
• URL: https://api.jasper.ai/scim/v2/Groups
• Watch out for: Group support scope (create/update/delete) should be confirmed with Jasper; IdP-pushed groups are the primary supported flow.

Request example

POST /scim/v2/Groups
Authorization: Bearer <scim_token>
Content-Type: application/scim+json
{
  "schemas": ["urn:ietf:params:scim:schemas:core:2.0:Group"],
  "displayName": "Sales Team",
  "members": [{"value": "abc123"}]
}

Response example

{
  "id": "grp2",
  "displayName": "Sales Team",
  "members": [{"value": "abc123"}]
}

• Rate limits: Rate limits for the Jasper content API are not publicly documented in detail. SCIM provisioning rate limits are not published.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: No official rate limit figures published as of research date. Contact Jasper support for enterprise rate limit details.
• Pagination method: none
• Default page size: 0
• Max page size: 0
• Pagination pointer: Not documented

• Webhooks available: No
• Webhook notes: No publicly documented webhook system for user lifecycle events in Jasper as of research date.
• Alternative event strategy: Use SCIM provisioning via IdP (Okta, Entra ID) for automated user lifecycle management; poll SCIM /Users endpoint for state changes if needed.

• SCIM available: Yes

• SCIM version: 2.0

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

• Endpoint: https://api.jasper.ai/scim/v2

• Supported operations: GET /Users, GET /Users/{id}, POST /Users, PATCH /Users/{id}, DELETE /Users/{id}, GET /Groups, POST /Groups, PATCH /Groups/{id}

Limitations:

• SSO (SAML) must be enabled before SCIM can be activated.
• SCIM bearer token is a single long-lived token generated in admin UI; no rotation mechanism documented.
• Supported IdPs are Okta and Microsoft Entra ID; other IdPs not officially documented.
• Group provisioning scope and behavior not fully documented publicly.
• SCIM filter query support extent is not officially documented.
• Available on Business plan (10+ seats, custom pricing) and Enterprise; not available on Creator or Pro plans.

The three primary automation scenarios are provisioning via Okta, deprovisioning departing employees, and group-push for workspace assignment.

For provisioning, the IdP sends POST /scim/v2/Users; Jasper creates the account and fires an invitation email, with seat billing starting immediately - bulk provisioning against a contract minimum should be validated before execution.

For deprovisioning, the IdP sends PATCH /scim/v2/Users/{id} with active=false; hard DELETE behavior and its seat-release timing are not clearly documented and should be confirmed with the Jasper account team before relying on it in automated offboarding flows.

Group push maps IdP groups to Jasper teams or workspaces via POST /scim/v2/Groups, but the group-to-workspace mapping behavior is not fully documented publicly. SCIM filter query support extent is also undocumented - test filter expressions against your instance before building automation that depends on them. The SCIM ID assigned by Jasper is internal; store it after initial provisioning for all subsequent PATCH and DELETE operations.

Provision new employee via Okta

1. In Jasper Admin → Security, enable SSO (SAML) with Okta.
2. Enable SCIM Provisioning and copy the generated bearer token.
3. In Okta, configure the Jasper SCIM app with base URL https://api.jasper.ai/scim/v2 and the bearer token.
4. Assign the new employee to the Jasper app in Okta.
5. Okta sends POST /scim/v2/Users to Jasper; user receives invite email and is active in Jasper.

Watch out for: User is billed as a seat immediately upon provisioning; ensure seat count aligns with contract before bulk provisioning.

Deprovision departing employee

1. In Okta (or Entra ID), unassign the user from the Jasper application or deactivate the user.
2. IdP sends PATCH /scim/v2/Users/{id} with active=false to Jasper.
3. Jasper deactivates the user account, revoking access.
4. Verify deactivation by checking user status in Jasper Admin → Members.

Watch out for: Deactivation (active=false) vs. hard DELETE may have different seat-release timing; confirm billing behavior with Jasper support.

Assign users to a team/workspace via group push

1. Create a group in Okta or Entra ID corresponding to a Jasper team (e.g., 'Marketing').
2. Add users to the group in the IdP.
3. Configure group push in the IdP SCIM app to sync the group to Jasper.
4. IdP sends POST /scim/v2/Groups with members list; Jasper creates or maps the group to a workspace.
5. Verify group membership in Jasper Admin → Teams.

Watch out for: Group-to-workspace mapping behavior in Jasper is not fully documented; test with a pilot group before rolling out broadly.

The identity graph risk with Jasper's SCIM implementation is concentrated in three areas. First, the single long-lived bearer token is a credential management liability - there is no documented rotation path, so token hygiene depends entirely on the operator.

Second, the active=false deactivation path and hard DELETE are not clearly differentiated in terms of seat release, meaning your identity graph may show a user as deprovisioned while Jasper continues billing the seat through the contract cycle. Third, role assignment (Admin vs.

Member) has no SCIM attribute mapping documented publicly - group push is the only IdP-driven mechanism for workspace assignment, and its behavior is partially undocumented.

Teams building an identity graph over Jasper should treat SCIM group membership as the authoritative signal for workspace access, poll GET /scim/v2/Users for active-state reconciliation, and maintain a side-channel confirmation step with Jasper billing for any deprovisioning event that should release a seat.