Vidyard User Management API Guide

Auth method: API Token (Bearer token passed via Authorization header or token query parameter)

Setup steps

1. Log in to your Vidyard account and navigate to Settings > Integrations > API.
2. Generate an API token for your organization.
3. Include the token in requests as a Bearer token: Authorization: Token , or as a query parameter ?token=.

List users in organization

• Method: GET
• URL: https://api.vidyard.com/dashboard/v1/users
• Watch out for: Pagination uses page parameter; no documented max page size beyond 100 per page.

Request example

GET /dashboard/v1/users?page=1
Authorization: Token <api_token>

Response example

{
  "users": [
    {"id": 123, "email": "user@example.com", "first_name": "Jane", "last_name": "Doe", "role": "member"}
  ]
}

Get a specific user

• Method: GET
• URL: https://api.vidyard.com/dashboard/v1/users/{user_id}
• Watch out for: Returns 404 if user_id does not belong to the authenticated organization.

Request example

GET /dashboard/v1/users/123
Authorization: Token <api_token>

Response example

{
  "user": {
    "id": 123,
    "email": "user@example.com",
    "first_name": "Jane",
    "last_name": "Doe"
  }
}

Create a user

• Method: POST
• URL: https://api.vidyard.com/dashboard/v1/users
• Watch out for: Duplicate email within the same organization will return an error.

Request example

POST /dashboard/v1/users
Authorization: Token <api_token>
Content-Type: application/json

{"user": {"email": "new@example.com", "first_name": "John", "last_name": "Smith"}}

Response example

{
  "user": {
    "id": 456,
    "email": "new@example.com",
    "first_name": "John",
    "last_name": "Smith"
  }
}

Update a user

• Method: PUT
• URL: https://api.vidyard.com/dashboard/v1/users/{user_id}
• Watch out for: Full object replacement semantics not confirmed; treat as partial update unless docs specify otherwise.

Request example

PUT /dashboard/v1/users/456
Authorization: Token <api_token>
Content-Type: application/json

{"user": {"first_name": "Jonathan"}}

Response example

{
  "user": {
    "id": 456,
    "email": "new@example.com",
    "first_name": "Jonathan",
    "last_name": "Smith"
  }
}

Delete a user

• Method: DELETE
• URL: https://api.vidyard.com/dashboard/v1/users/{user_id}
• Watch out for: Deleting a user may reassign or orphan their video content; verify content ownership before deletion.

Request example

DELETE /dashboard/v1/users/456
Authorization: Token <api_token>

Response example

HTTP 204 No Content

List groups (teams)

• Method: GET
• URL: https://api.vidyard.com/dashboard/v1/groups
• Watch out for: Group/team availability may depend on plan tier.

Request example

GET /dashboard/v1/groups
Authorization: Token <api_token>

Response example

{
  "groups": [
    {"id": 10, "name": "Sales Team"}
  ]
}

Add user to group

• Method: POST
• URL: https://api.vidyard.com/dashboard/v1/groups/{group_id}/users
• Watch out for: Exact request body schema not fully confirmed in public docs; verify against current API reference.

Request example

POST /dashboard/v1/groups/10/users
Authorization: Token <api_token>
Content-Type: application/json

{"user_id": 456}

Response example

HTTP 201 Created

• Rate limits: Vidyard's official documentation does not publicly specify numeric rate limits or rate-limit headers.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No explicit rate-limit tiers, headers, or Retry-After behavior documented in official sources as of research date.

• Pagination method: offset

• Default page size: 100

• Max page size: 100

• Pagination pointer: page

• Webhooks available: No

• Webhook notes: Vidyard's official developer documentation does not describe user-management webhooks. Vidyard does support video-event webhooks (e.g., video viewed) but not user lifecycle events.

• Alternative event strategy: Poll the /users endpoint periodically to detect user changes, or use SSO/SCIM provisioning for automated lifecycle management on Enterprise plans.

• SCIM available: No
• SCIM version: Not documented
• Plan required: Enterprise
• Endpoint: Not documented

Limitations:

• Vidyard does not expose a native SCIM 2.0 endpoint according to official documentation.
• Enterprise plan includes SSO support (Okta, Entra ID, Google Workspace) which may enable IdP-driven provisioning via SSO JIT, but a dedicated SCIM endpoint is not documented.
• The context reference indicates has_native_scim=false; no SCIM endpoint should be assumed.

Bulk onboarding requires individual POST /users calls per user - there is no batch-create endpoint.

Capture the returned user id from each response before attempting group assignment via POST /groups/{group_id}/users.

Implement idempotency checks on email to avoid duplicate-user errors on retry.

For offboarding, retrieve the user_id via GET /users filtered by email, audit content ownership, then issue DELETE /users/{user_id}.

Deletion may orphan video assets;

confirm your org's content reassignment policy before automating this step at scale.

Building an identity graph across your SaaS stack requires reconciling Vidyard user records (id, email, role, created_at, updated_at) against your IdP's user directory.

Because Vidyard does not expose a native SCIM 2.0 endpoint, the REST API is the only programmatic source of truth for user state.

Poll GET /users on a scheduled basis and diff against your identity graph to detect role drift, inactive accounts, or users present in Vidyard but absent from the IdP.

Bulk-invite new team members via API

1. Authenticate using the organization API token.
2. POST to /dashboard/v1/users for each new user with email, first_name, last_name.
3. Capture the returned user id for each created user.
4. Optionally POST each user id to /dashboard/v1/groups/{group_id}/users to assign them to the correct team.

Watch out for: There is no documented bulk-create endpoint; each user requires an individual POST request. Implement retry logic for transient errors.

Deprovision a departed employee

1. GET /dashboard/v1/users to locate the user by email and retrieve their user_id.
2. Review the user's video content ownership before deletion.
3. DELETE /dashboard/v1/users/{user_id} to remove the user from the organization.

Watch out for: Deleting a user may orphan their video assets. Confirm content reassignment policy with Vidyard support before automating offboarding.

Sync users from an IdP using SSO (Enterprise)

1. Ensure the organization is on an Enterprise plan with SSO enabled.
2. Configure your IdP (Okta, Entra ID, or Google Workspace) with Vidyard's SSO settings per the Vidyard SSO knowledge base article.
3. Enable JIT provisioning in the IdP configuration so users are created in Vidyard on first SSO login.
4. Use the REST API (/dashboard/v1/users) to audit and reconcile user records as needed.

Watch out for: Vidyard does not provide a native SCIM endpoint; automated deprovisioning on IdP-side user removal is not guaranteed without a SCIM connector. Manual API-based deprovisioning may be required.

The most significant architectural caveat is the absence of a native SCIM endpoint. Enterprise SSO (Okta, Entra ID, Google Workspace) enables JIT provisioning on first login, but automated deprovisioning triggered by IdP-side user removal is not guaranteed without a SCIM connector.

This means offboarding gaps are possible: a user disabled in your IdP may retain an active Vidyard session or API-accessible account until a separate DELETE call is issued.

Webhooks for user lifecycle events (create, update, delete) are not available. Vidyard's webhook support covers video-event signals only, so any identity graph that depends on event-driven updates must fall back to polling GET /users. There is no documented Retry-After header, no confirmed total-count field in paginated responses, and PUT /users/{user_id} update semantics (full replacement vs.

partial) are not explicitly confirmed in public docs - treat all writes as requiring full object payloads until verified against the live API.