Zoom User Management API Guide

Auth method: OAuth 2.0 – Server-to-Server OAuth app (for backend/automated use) or Account-level OAuth app. JWT authentication was deprecated June 2023 and is no longer supported.

Setup steps

1. Log in to the Zoom App Marketplace (marketplace.zoom.us).
2. Create a 'Server-to-Server OAuth' app for automated/backend use.
3. Add required user-management scopes (e.g., user:read:admin, user:write:admin).
4. Activate the app and note the Account ID, Client ID, and Client Secret.
5. Exchange credentials for an access token: POST https://zoom.us/oauth/token?grant_type=account_credentials&account_id={accountId} with Basic auth header (base64-encoded clientId:clientSecret).
6. Use the returned access_token as a Bearer token in the Authorization header for all API calls.

Required scopes

List Users

• Method: GET
• URL: https://api.zoom.us/v2/users
• Watch out for: next_page_token expires after 15 minutes. Max page_size is 300. Rate limit category is 'Medium' (20 req/s), not 'Light'.

Request example

GET /v2/users?status=active&page_size=300&next_page_token=abc123
Authorization: Bearer {token}

Response example

{
  "total_records": 450,
  "next_page_token": "xyz789",
  "users": [
    {"id":"abc","email":"user@example.com","type":2,"status":"active"}
  ]
}

Get User

• Method: GET
• URL: https://api.zoom.us/v2/users/{userId}
• Watch out for: Use 'me' as userId to get the token owner's profile. Fields like host_key only appear with admin scope.

Request example

GET /v2/users/abc123
Authorization: Bearer {token}

Response example

{
  "id": "abc123",
  "email": "user@example.com",
  "first_name": "Jane",
  "last_name": "Doe",
  "type": 2,
  "status": "active"
}

Create User

• Method: POST
• URL: https://api.zoom.us/v2/users
• Watch out for: action controls flow: 'create' sends invite email (user stays pending); 'autoCreate' skips email but requires SSO; 'custCreate' is API-managed with no email; 'ssoCreate' requires SSO. Wrong action is a common integration error.

Request example

POST /v2/users
{
  "action": "autoCreate",
  "user_info": {
    "email": "new@example.com",
    "type": 2,
    "first_name": "Jane",
    "last_name": "Doe"
  }
}

Response example

{
  "id": "newUserId",
  "email": "new@example.com",
  "type": 2
}

Update User

• Method: PATCH
• URL: https://api.zoom.us/v2/users/{userId}
• Watch out for: Returns 204 with no body on success. Email cannot be changed here; use PUT /users/{userId}/email. Status cannot be changed here; use PUT /users/{userId}/status.

Request example

PATCH /v2/users/abc123
{
  "first_name": "Janet",
  "dept": "Engineering",
  "timezone": "America/Chicago"
}

Response example

HTTP 204 No Content

Delete User

• Method: DELETE
• URL: https://api.zoom.us/v2/users/{userId}
• Watch out for: Default action is 'disassociate' (removes from account, Zoom account persists). Use action=delete for permanent removal. transfer_email reassigns meetings/webinars before deletion.

Request example

DELETE /v2/users/abc123?action=delete&transfer_email=manager@example.com
Authorization: Bearer {token}

Response example

HTTP 204 No Content

Update User Status (Activate/Deactivate)

• Method: PUT
• URL: https://api.zoom.us/v2/users/{userId}/status
• Watch out for: action must be 'activate' or 'deactivate'. Deactivated users cannot sign in but retain data and still consume a license seat.

Request example

PUT /v2/users/abc123/status
{
  "action": "deactivate"
}

Response example

HTTP 204 No Content

Update User Email

• Method: PUT
• URL: https://api.zoom.us/v2/users/{userId}/email
• Watch out for: New email must not already exist in Zoom. User receives a confirmation email. SSO users may need a separate IdP update.

Request example

PUT /v2/users/abc123/email
{
  "email": "newemail@example.com"
}

Response example

HTTP 204 No Content

Get/Update User Settings

• Method: GET
• URL: https://api.zoom.us/v2/users/{userId}/settings
• Watch out for: Settings are nested by category. Use PATCH /users/{userId}/settings to update. Some settings require specific add-ons or plan levels to take effect.

Request example

GET /v2/users/abc123/settings
Authorization: Bearer {token}

Response example

{
  "schedule_meeting": {"host_video": true},
  "recording": {"local_recording": false},
  "feature": {"meeting_capacity": 100}
}

• Rate limits: Zoom enforces per-second rate limits per API category. User endpoints fall under 'Light' or 'Medium' categories. Daily caps also apply and vary by plan.
• Rate-limit headers: Yes
• Retry-After header: Yes
• Rate-limit notes: Response headers include X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Category, and Retry-After (on HTTP 429). List Users is categorized as 'Medium' (20 req/s). Exceeding limits returns HTTP 429.
• Pagination method: token
• Default page size: 30
• Max page size: 300
• Pagination pointer: next_page_token

• Webhooks available: Yes
• Webhook notes: Zoom supports webhooks via a Webhook-only app or OAuth app configured in the Marketplace. Subscribe to user-related events to receive real-time HTTP POST notifications to a configured endpoint URL. Endpoint must respond with HTTP 200 within a timeout window.
• Alternative event strategy: Poll GET /v2/users with status filters if webhooks are not feasible. Zoom Dashboard API provides activity data for audit purposes.
• Webhook events: user.created, user.updated, user.deleted, user.deactivated, user.activated, user.invitation_accepted, user.signed_in, user.signed_out, user.presence_status_updated

• SCIM available: Yes

• SCIM version: 2.0

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

• Endpoint: https://api.zoom.us/scim2

• 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/deprovision user), GET /Groups (list groups), POST /Groups (create group), PATCH /Groups/{id} (update group members), DELETE /Groups/{id} (delete group)

Limitations:

• Bearer token authentication no longer supported; OAuth 2.0 Authorization Code Grant is required.
• Requires Business plan or higher with SSO enabled.
• Email domain must be associated with the Zoom account.
• Users must have SSO login type configured for SSO-based provisioning.
• Officially supported IdPs: Okta, Azure AD (Entra ID), OneLogin. Google Workspace is not natively supported.
• AD Sync Tool available for on-premises Active Directory scenarios.
• SCIM endpoint path is /scim2 (not /scim); older documentation may reference the deprecated /scim path.

Three scenarios cover the majority of production integration patterns.

For SSO-based provisioning with no invite email, POST /v2/users with action='autoCreate' and type=2. This requires SSO to be configured and the email domain verified on the account; without those prerequisites, the call fails silently or falls back to pending status. Use action='create' if SSO is not in place - it sends an invite email and leaves the user in pending status until accepted.

For offboarding, the correct sequence is: deactivate immediately via PUT /v2/users/{userId}/status with action='deactivate', then downgrade the license type to 1 (Basic) via PATCH /v2/users/{userId} to free the seat, then permanently delete via DELETE /v2/users/{userId}?action=delete&transfer_email={manager} to reassign meetings and recordings before removal. Skipping the type downgrade before deletion still frees the seat, but the transfer_email param on DELETE is the only mechanism to preserve scheduled meetings and cloud recordings - omitting it results in unrecoverable data loss.

For bulk directory sync, GET /v2/users?status=active&page_size=300 with next_page_token pagination. The token expires after 15 minutes; for large accounts, complete pagination in a single run or implement retry-from-page-one logic. Pair the initial full load with webhooks (user.created, user.updated, user.deleted) to keep the identity graph current incrementally without repeated full scans.

Provision a new licensed user via SSO (no invite email)

1. Obtain an OAuth 2.0 access token: POST https://zoom.us/oauth/token?grant_type=account_credentials&account_id={accountId} with Basic auth (base64 clientId:clientSecret).
2. POST /v2/users with action='autoCreate', user_info.type=2, and the user's SSO-linked email.
3. Verify the user is active: GET /v2/users/{userId} and confirm status='active'.
4. Optionally assign to a group: POST /v2/groups/{groupId}/members with the new user's ID.
5. Optionally configure user settings: PATCH /v2/users/{userId}/settings.

Watch out for: autoCreate requires SSO to be configured on the account and the email domain to be verified. Without SSO, use action='create', which sends an invite email and leaves the user in 'pending' status until accepted.

Offboard a user when they leave the organization

1. Look up the user by email: GET /v2/users/{email} (email can be used as userId).
2. Deactivate the user immediately: PUT /v2/users/{userId}/status with body {"action": "deactivate"}.
3. Downgrade license to Basic to free the seat: PATCH /v2/users/{userId} with {"type": 1}.
4. Transfer meetings and recordings: DELETE /v2/users/{userId}?action=delete&transfer_email=manager@example.com for permanent removal with data transfer.

Watch out for: Deactivation alone does not free a license seat. The transfer_email query param on DELETE reassigns meetings and webinars to another user before permanent deletion. Deleted users cannot be recovered.

Bulk-list all active users and sync to an external directory

1. GET /v2/users?status=active&page_size=300 to fetch the first page.
2. Check response for next_page_token; if present, repeat GET with &next_page_token={token}.
3. Continue until next_page_token is absent or empty; use total_records for progress tracking.
4. Map Zoom user fields (id, email, first_name, last_name, type, dept, role_id) to the external directory schema.
5. Subscribe to user.created, user.updated, and user.deleted webhooks to keep the sync incremental after the initial load.

Watch out for: next_page_token expires in 15 minutes. For large accounts, complete pagination quickly or implement retry-from-start logic. List Users is rate-limited at 20 req/s (Medium category).

The most consequential API trap is the action parameter on POST /v2/users. Four values exist - create, autoCreate, custCreate, ssoCreate - each with different email, SSO, and activation behaviors.

Choosing the wrong action produces a user in an unexpected state (pending instead of active, or active without SSO linkage) that is not immediately visible in the API response, only in a subsequent GET. This is the leading cause of provisioning pipeline failures in Zoom integrations.

The DELETE endpoint defaults to disassociate, not permanent deletion. Without action=delete, the user is removed from the account but their Zoom identity persists, which creates orphaned records in any identity graph that relies on Zoom user IDs as a join key.

Pass action=delete explicitly for permanent removal, and always supply transfer_email to avoid silent recording loss.

Rate limits require attention at scale: List Users is categorized as Medium (20 req/s), not Light (30 req/s). The response headers X-RateLimit-Remaining and Retry-After are present on 429 responses and should drive backoff logic.

SCIM is available at https://api.zoom.us/scim2 (note: scim2, not scim) on Business plan or higher with SSO enabled; Bearer token auth to the SCIM endpoint is no longer supported and must be replaced with OAuth 2.0 Authorization Code Grant.