BlueJeans User Management API Guide

Auth method: OAuth 2.0 (client credentials grant for server-to-server; password grant for user-context)

Setup steps

1. NOTE: BlueJeans was shut down in early 2024. The following steps are historical.
2. Register an application in the BlueJeans Developer Portal to obtain a client_id and client_secret.
3. POST to https://api.bluejeans.com/oauth2/token with grant_type=client_credentials and your credentials to obtain an access_token.
4. Include the access_token as a Bearer token in the Authorization header for all subsequent API requests.
5. Tokens had a limited TTL; refresh by repeating the token request.

Required scopes

List Enterprise Users

• Method: GET
• URL: https://api.bluejeans.com/v1/enterprise/{enterpriseId}/users
• Watch out for: enterpriseId must match the enterprise associated with the OAuth token.

Request example

GET /v1/enterprise/12345/users?pageSize=100&pageNumber=0
Authorization: Bearer {access_token}

Response example

{
  "count": 2,
  "users": [
    {"id": 1001, "username": "alice@example.com", "firstName": "Alice"},
    {"id": 1002, "username": "bob@example.com", "firstName": "Bob"}
  ]
}

Get User

• Method: GET
• URL: https://api.bluejeans.com/v1/enterprise/{enterpriseId}/users/{userId}
• Watch out for: userId is the integer BlueJeans internal ID, not the email.

Request example

GET /v1/enterprise/12345/users/1001
Authorization: Bearer {access_token}

Response example

{
  "id": 1001,
  "username": "alice@example.com",
  "firstName": "Alice",
  "lastName": "Smith",
  "emailId": "alice@example.com"
}

Create User

• Method: POST
• URL: https://api.bluejeans.com/v1/enterprise/{enterpriseId}/users
• Watch out for: Requires Enterprise plan. User receives an activation email upon creation.

Request example

POST /v1/enterprise/12345/users
Authorization: Bearer {access_token}
Content-Type: application/json
{"username":"carol@example.com","firstName":"Carol","lastName":"Jones","emailId":"carol@example.com"}

Response example

{
  "id": 1003,
  "username": "carol@example.com",
  "firstName": "Carol",
  "lastName": "Jones"
}

Update User

• Method: PUT
• URL: https://api.bluejeans.com/v1/enterprise/{enterpriseId}/users/{userId}
• Watch out for: Full PUT semantics; omitting optional fields may reset them. Verify field behavior before bulk updates.

Request example

PUT /v1/enterprise/12345/users/1003
Authorization: Bearer {access_token}
Content-Type: application/json
{"firstName":"Caroline","title":"Manager"}

Response example

{
  "id": 1003,
  "firstName": "Caroline",
  "title": "Manager"
}

Delete User

• Method: DELETE
• URL: https://api.bluejeans.com/v1/enterprise/{enterpriseId}/users/{userId}
• Watch out for: Deletion is immediate and irreversible. User loses access to all meetings and recordings.

Request example

DELETE /v1/enterprise/12345/users/1003
Authorization: Bearer {access_token}

Response example

HTTP 200 OK
{}

Search Users

• Method: GET
• URL: https://api.bluejeans.com/v1/enterprise/{enterpriseId}/users?fields=emailId&emailId={email}
• Watch out for: Filter parameter support was limited; not all fields were filterable.

Request example

GET /v1/enterprise/12345/users?fields=emailId&emailId=alice@example.com
Authorization: Bearer {access_token}

Response example

{
  "count": 1,
  "users": [
    {"id": 1001, "emailId": "alice@example.com"}
  ]
}

• Rate limits: BlueJeans imposed API rate limits but did not publish explicit per-plan numeric limits in public documentation.
• Rate-limit headers: Unknown
• Retry-After header: Unknown
• Rate-limit notes: Rate limit details were not publicly documented before service shutdown. HTTP 429 was returned when limits were exceeded.
• Pagination method: offset
• Default page size: 100
• Max page size: 1000
• Pagination pointer: pageSize / pageNumber

• Webhooks available: No
• Webhook notes: BlueJeans did not offer a documented user-management webhook system in its public API before shutdown.
• Alternative event strategy: Polling the list users endpoint was the recommended approach for detecting user changes.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise (requires SSO enabled; was in BETA at time of shutdown)

• Endpoint: https://api.bluejeans.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} (delete user)

Limitations:

• Was in BETA status before service shutdown in early 2024.
• Requires SSO (SAML) to be configured as a prerequisite.
• Only available on Enterprise plan.
• Group provisioning support was limited or undocumented.
• Service is no longer operational.

Three integration patterns were documented before shutdown. First, direct REST provisioning: POST to /v1/enterprise/{enterpriseId}/users with firstName, lastName, username, and emailId; the integer id returned must be stored for subsequent PUT or DELETE calls, as email-based lookups required a separate search step.

Second, user deprovisioning: resolve the integer userId via GET with an emailId filter, then DELETE - no suspend or soft-delete option existed, making deletion immediate and irreversible. Third, IdP-driven SCIM lifecycle: configure the SCIM 2.

0 base URL in Okta, Entra ID, or OneLogin, supply a Bearer token from the admin console, and map userName, name. givenName, name.

familyName, and emails - but this path required SSO (SAML) to be pre-configured and was in beta status at shutdown. None of these endpoints are reachable today.

Provision a new enterprise user via REST API

1. Obtain OAuth 2.0 access_token via POST to /oauth2/token with client_credentials.
2. POST to /v1/enterprise/{enterpriseId}/users with firstName, lastName, username, emailId in the request body.
3. Store the returned integer id for future update or delete operations.
4. User receives an activation email automatically.

Watch out for: Requires Enterprise plan. Service is no longer operational as of early 2024.

Deprovision a user when they leave the organization

1. Obtain OAuth 2.0 access_token.
2. GET /v1/enterprise/{enterpriseId}/users?emailId={email} to resolve the integer userId.
3. DELETE /v1/enterprise/{enterpriseId}/users/{userId}.
4. Confirm HTTP 200 response; deletion is immediate and irreversible.

Watch out for: No soft-delete or suspend option was documented; deletion removed all user data and meeting access.

Automate user lifecycle via SCIM 2.0 with an IdP

1. Enable SSO (SAML) on the BlueJeans Enterprise account.
2. Configure your IdP (e.g., Okta, Entra ID, OneLogin) with the BlueJeans SCIM 2.0 base URL: https://api.bluejeans.com/scim/v2.
3. Provide the SCIM Bearer token generated from the BlueJeans admin console to the IdP.
4. Map IdP user attributes to SCIM User schema fields (userName, name.givenName, name.familyName, emails).
5. Test provisioning with a pilot user before enabling for all users.

Watch out for: SCIM was in BETA and required Enterprise plan plus SSO prerequisite. Service is no longer operational.

The primary integration risk was the full-replace semantics on PUT /users/{userId}: omitting optional fields could silently reset them, making bulk update scripts destructive without careful field validation. Rate limits were never publicly documented; HTTP 429 was the only signal, with no Retry-After header, making backoff logic difficult to calibrate.

SCIM's beta status meant group provisioning support was limited or undocumented, and the SSO prerequisite meant any IdP misconfiguration blocked the entire provisioning pipeline. The integer-only internal user ID model added a mandatory lookup step to every delete or update workflow triggered by an external system using email as the primary identifier.