Domo User Management API Guide

Auth method: OAuth 2.0 (client_credentials grant)

Setup steps

1. Log in to Domo and navigate to developer.domo.com.
2. Create a new client application under 'My Client IDs' to obtain a client_id and client_secret.
3. Assign the required scopes (e.g., 'user') to the client application.
4. POST to https://api.domo.com/oauth/token?grant_type=client_credentials&scope=user with Basic auth (client_id:client_secret) to receive a Bearer access_token.
5. Include the access_token as 'Authorization: Bearer ' in all subsequent API requests.
6. Tokens expire; re-request as needed (expiry returned in token response as expires_in seconds).

Required scopes

List Users

• Method: GET
• URL: https://api.domo.com/v1/users
• Watch out for: Returns an array (not a wrapped object). Use offset+limit for pagination; max limit is 500 per request.

Request example

GET /v1/users?limit=50&offset=0
Authorization: Bearer <token>

Response example

[
  {
    "id": 123456789,
    "name": "Jane Doe",
    "email": "jane@example.com",
    "role": "Editor"
  }
]

Get User

• Method: GET
• URL: https://api.domo.com/v1/users/{userId}
• Watch out for: userId is a numeric integer, not a UUID or email string.

Request example

GET /v1/users/123456789
Authorization: Bearer <token>

Response example

{
  "id": 123456789,
  "name": "Jane Doe",
  "email": "jane@example.com",
  "role": "Editor",
  "title": "Analyst",
  "department": "Finance"
}

Create User

• Method: POST
• URL: https://api.domo.com/v1/users
• Watch out for: The sendInvite query parameter (true/false) controls whether an invitation email is sent. Defaults to true if omitted.

Request example

POST /v1/users?sendInvite=false
Authorization: Bearer <token>
Content-Type: application/json
{
  "name": "John Smith",
  "email": "john@example.com",
  "role": "Participant"
}

Response example

{
  "id": 987654321,
  "name": "John Smith",
  "email": "john@example.com",
  "role": "Participant"
}

Update User

• Method: PUT
• URL: https://api.domo.com/v1/users/{userId}
• Watch out for: This is a full PUT (replace), not a partial PATCH. Omitting optional fields may clear existing values. Always include all desired fields.

Request example

PUT /v1/users/987654321
Authorization: Bearer <token>
Content-Type: application/json
{
  "name": "John Smith",
  "role": "Editor",
  "title": "Senior Analyst"
}

Response example

{
  "id": 987654321,
  "name": "John Smith",
  "email": "john@example.com",
  "role": "Editor",
  "title": "Senior Analyst"
}

Delete User

• Method: DELETE
• URL: https://api.domo.com/v1/users/{userId}
• Watch out for: Deletion is permanent and cannot be undone via API. Content owned by the deleted user may be reassigned or lost.

Request example

DELETE /v1/users/987654321
Authorization: Bearer <token>

Response example

HTTP 204 No Content

Get User by Email (search)

• Method: GET
• URL: https://api.domo.com/v1/users
• Watch out for: There is no native filter-by-email query parameter in v1. Callers must paginate through all users and filter client-side, or use SCIM /Users?filter=userName eq "email" for server-side filtering.

Request example

GET /v1/users?limit=500&offset=0
Authorization: Bearer <token>

Response example

[
  {"id": 123, "email": "target@example.com", ...}
]

Get OAuth Token

• Method: POST
• URL: https://api.domo.com/oauth/token
• Watch out for: Tokens expire in 3600 seconds (1 hour). Applications must handle token refresh proactively to avoid 401 errors mid-operation.

Request example

POST /oauth/token?grant_type=client_credentials&scope=user
Authorization: Basic base64(client_id:client_secret)

Response example

{
  "access_token": "eyJ...",
  "token_type": "bearer",
  "expires_in": 3600,
  "scope": "user"
}

List Groups (for group membership management)

• Method: GET
• URL: https://api.domo.com/v1/groups
• Watch out for: Group membership management (add/remove users from groups) requires separate endpoints under /v1/groups/{groupId}/users. The 'user' scope alone may not be sufficient; verify the client app has appropriate permissions.

Request example

GET /v1/groups?limit=50&offset=0
Authorization: Bearer <token>

Response example

[
  {"id": 111, "name": "Finance Team", "active": true}
]

• Rate limits: Domo enforces per-customer rate limits on API calls. The Users API is subject to a limit of 3,000 requests per minute across all API calls for a given customer instance.
• Rate-limit headers: Yes
• Retry-After header: No
• Rate-limit notes: HTTP 429 is returned when the rate limit is exceeded. Domo recommends exponential backoff. The X-RateLimit-Limit and X-RateLimit-Remaining headers are present in responses. No official per-endpoint sub-limits are documented.
• Pagination method: offset
• Default page size: 50
• Max page size: 500
• Pagination pointer: offset and limit

• Webhooks available: No
• Webhook notes: Domo does not offer native outbound webhooks for user lifecycle events (create, update, delete) via the standard API. Event-driven automation for user changes is not natively supported through a webhook subscription model.
• Alternative event strategy: Use Domo's Workflows (automation builder) or poll the Users API on a schedule to detect changes. For provisioning events, SCIM with an IdP (Okta, Entra ID) provides near-real-time push-based provisioning.

• SCIM available: Yes

• SCIM version: 2.0

• Plan required: Enterprise

• Endpoint: https://.domo.com/api/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 attributes), DELETE /Users/{id} (delete/deprovision user), GET /Groups (list groups), POST /Groups (create group), PATCH /Groups/{id} (update group membership), DELETE /Groups/{id} (delete group), GET /ServiceProviderConfig, GET /Schemas

Limitations:

• Requires Enterprise plan.
• SSO must be configured and enabled as a prerequisite before SCIM can be activated.
• SCIM provisioning is configured through the IdP (Okta, Entra ID); Domo acts as the SCIM service provider.
• Custom Domo roles may not map cleanly via SCIM group-to-role provisioning without additional configuration.
• SCIM filter support (e.g., filter=userName eq) is available for user lookups but complex filters may not be fully supported.
• Bearer token for SCIM is generated separately within Domo's SSO/SCIM configuration UI, not via the OAuth client_credentials flow.

Three primary automation scenarios are well-supported by the API:

• Bulk onboarding from an HR system: POST /v1/users per employee with sendInvite=false to suppress premature invitation emails during batch creation. Store the returned numeric id for downstream group membership calls (PATCH /v1/groups/{groupId}/users). Trigger invitations in a controlled second pass once the full batch is validated.

• Deprovisioning a departed employee: There is no server-side email filter, so locate the user's numeric id by paginating GET /v1/users and matching email client-side. Prefer PUT /v1/users/{userId} with active=false over DELETE to preserve content ownership; DELETE /v1/users/{userId} is permanent and irreversible via API, and owned content (cards, DataSets) may be orphaned. Enterprise customers using Okta or Entra ID should route deprovisioning through SCIM, which triggers deactivation or deletion in Domo automatically.

• Audit and reconciliation against an external directory: Paginate GET /v1/users at limit=500 until a page returns fewer results than the limit, then diff the full list against the external directory by email. Flag users present in Domo but absent from the directory as deprovisioning candidates. At scale, full pagination can approach rate limits; schedule reconciliation jobs during off-peak hours.

Bulk onboard new employees from HR system

1. Obtain OAuth token via POST /oauth/token?grant_type=client_credentials&scope=user.
2. For each new employee record from HR, POST /v1/users with name, email, role, title, department, and sendInvite=false.
3. Store the returned numeric user id for future updates.
4. After all users are created, trigger invitation emails in a second pass or rely on SSO for first login.
5. Optionally, PATCH /v1/groups/{groupId}/users to add users to relevant Domo groups.

Watch out for: sendInvite defaults to true; always explicitly set sendInvite=false during bulk imports to prevent premature invitation emails before onboarding is complete.

Deprovision a departed employee

1. Obtain OAuth token with 'user' scope.
2. GET /v1/users with pagination to find the user's numeric id by matching email client-side (no server-side email filter in v1).
3. Optionally, PUT /v1/users/{userId} with active=false to deactivate without deleting, preserving content ownership.
4. If full removal is required, DELETE /v1/users/{userId}.
5. If using SCIM via Okta/Entra, deprovisioning the user in the IdP will automatically trigger SCIM DELETE or deactivation in Domo.

Watch out for: DELETE is permanent. Prefer deactivation (active=false via PUT) if content preservation is important. SCIM-based deprovisioning via IdP is the recommended approach for Enterprise customers.

Sync Domo users to an external directory (audit/reconciliation)

1. Obtain OAuth token with 'user' scope.
2. GET /v1/users?limit=500&offset=0 and collect all pages by incrementing offset until fewer than limit results are returned.
3. Compare the full user list against the external directory (e.g., Active Directory, HR system) by email.
4. Identify users present in Domo but not in the directory (candidates for deprovisioning).
5. Identify users in the directory but not in Domo (candidates for provisioning).
6. Execute create/delete/update calls as needed based on reconciliation results.

Watch out for: With no server-side email filter, full pagination is required for reconciliation. At 500 users/page, large instances may require many requests and approach rate limits. Schedule reconciliation jobs during off-peak hours.

The most consequential API caveat is the PUT-only update model: GET /v1/users/{userId} first, merge your changes into the full object, then PUT the complete payload. Omitting any field on a PUT will silently clear its existing value. There is no PATCH on the v1 REST API (PATCH is available only via SCIM).

A second structural trap is the absence of a server-side email filter on the v1 Users endpoint - any lookup by email requires full pagination, which is expensive at scale and can exhaust rate limits in large instances.

Custom roles defined in the Domo UI are not assignable via the v1 role field; only the five default role name strings (Admin, Privileged, Editor, Participant, Social) are valid, and they are case-sensitive.

Finally, the SCIM Bearer token and the OAuth client_credentials token are entirely separate credentials with separate generation flows - conflating them is a common integration failure point.

Teams building on top of Stitchflow's MCP server with 60+ deep IT/identity integrations can surface Domo user data into a unified identity graph without re-implementing pagination, token refresh, or the PUT-merge pattern from scratch.