Redash User Management API Guide

Auth method: API Key (passed as query parameter api_key or via Authorization: Key <api_key> header)

Setup steps

1. Log in to Redash as an admin user.
2. Navigate to the user's profile page (Settings → Profile or /users/).
3. Copy the API Key shown under 'API Key'.
4. Include it in requests as a query parameter: ?api_key=, or as an HTTP header: Authorization: Key .
5. Admin-level API keys are required for user-management operations (create, update, disable).

List all users

• Method: GET
• URL: /api/users
• Watch out for: Returns all users in the organization. No pagination; large orgs may return large payloads.

Request example

GET /api/users?api_key=<admin_key>

Response example

[
  {
    "id": 1,
    "name": "Alice",
    "email": "alice@example.com",
    "is_disabled": false,
    "groups": [1, 2]
  }
]

Get single user

• Method: GET
• URL: /api/users/{id}
• Watch out for: Use id=current to retrieve the authenticated user's own record.

Request example

GET /api/users/42?api_key=<admin_key>

Response example

{
  "id": 42,
  "name": "Bob",
  "email": "bob@example.com",
  "is_disabled": false,
  "api_key": "abc123",
  "groups": [1]
}

Create user (invite)

• Method: POST
• URL: /api/users
• Watch out for: Creates user and sends an invitation email. Requires admin API key. Password is not set until the user accepts the invite.

Request example

POST /api/users
Content-Type: application/json

{
  "name": "Carol",
  "email": "carol@example.com"
}

Response example

{
  "id": 99,
  "name": "Carol",
  "email": "carol@example.com",
  "is_invitation_pending": true
}

Update user

• Method: POST
• URL: /api/users/{id}
• Watch out for: Redash uses POST (not PATCH/PUT) for updates. Admins can update any user; non-admins can only update their own profile.

Request example

POST /api/users/42
Content-Type: application/json

{
  "name": "Bob Updated",
  "email": "bob2@example.com"
}

Response example

{
  "id": 42,
  "name": "Bob Updated",
  "email": "bob2@example.com"
}

Disable user

• Method: POST
• URL: /api/users/{id}/disable
• Watch out for: Disabling is the recommended deactivation method; there is no hard-delete endpoint exposed via the REST API.

Request example

POST /api/users/42/disable?api_key=<admin_key>

Response example

{
  "id": 42,
  "is_disabled": true
}

Re-enable user

• Method: DELETE
• URL: /api/users/{id}/disable
• Watch out for: Counter-intuitively uses DELETE on the /disable sub-resource to re-enable an account.

Request example

DELETE /api/users/42/disable?api_key=<admin_key>

Response example

{
  "id": 42,
  "is_disabled": false
}

Regenerate API key

• Method: POST
• URL: /api/users/{id}/regenerate_api_key
• Watch out for: Immediately invalidates the previous API key for that user.

Request example

POST /api/users/42/regenerate_api_key?api_key=<admin_key>

Response example

{
  "api_key": "newkey456"
}

Send password reset email

• Method: GET
• URL: /api/users/{id}/reset_password
• Watch out for: Only applicable when local password authentication is enabled. Has no effect when SSO is the sole auth method.

Request example

GET /api/users/42/reset_password?api_key=<admin_key>

Response example

{}

• Rate limits: No rate limiting is documented in official Redash sources. Self-hosted deployments inherit whatever limits the operator configures at the infrastructure level.

• Rate-limit headers: No

• Retry-After header: No

• Rate-limit notes: No official rate-limit documentation exists. Operator-configured reverse-proxy limits (e.g., nginx) may apply.

• Pagination method: none

• Default page size: 0

• Max page size: 0

• Pagination pointer: Not documented

• Webhooks available: No

• Webhook notes: Redash does not provide a native webhook system for user lifecycle events.

• Alternative event strategy: Poll /api/users periodically to detect changes, or monitor application logs / database events on self-hosted deployments.

• SCIM available: No
• SCIM version: Not documented
• Plan required: N/A
• Endpoint: Not documented

Limitations:

• No SCIM support exists in the open-source Redash codebase.
• IdP integrations (Okta, Entra ID, OneLogin) are limited to SSO/SAML authentication; user provisioning must be done via the REST API or manually.
• The Redash cloud service was discontinued in November 2021; no hosted SCIM offering exists.

Three automation scenarios are well-supported by the API.

First, provisioning: POST /api/users with {name, email} creates the user and triggers an invitation email; group assignment is a separate POST /api/groups/{group_id}/members call using the returned user_id - group IDs must be resolved via GET /api/groups beforehand, as they are not accepted in the create payload.

Second, deprovisioning: GET /api/users to resolve the user's id by email, then POST /api/users/{id}/disable; follow with POST /api/users/{id}/regenerate_api_key to immediately invalidate their personal key. Note that disabling does not remove group memberships or retroactively revoke access to shared resources.

Third, directory sync: fetch the full user list via GET /api/users, diff against the external directory on email and is_disabled, create missing users, and disable users absent from the directory.

No delta or incremental endpoint exists, so every sync cycle fetches the complete list.

Provision a new user and assign to a group

1. POST /api/users with {name, email} using an admin API key to create the user and trigger an invitation email.
2. Note the returned user id.
3. POST /api/groups/{group_id}/members with {user_id: } to add the user to the desired group.
4. User accepts the invitation email and sets their password to complete onboarding.

Watch out for: Group membership is managed via /api/groups/{id}/members, not directly in the user create payload. Confirm group IDs via GET /api/groups first.

Deactivate a departed user

1. GET /api/users to find the user's id by email.
2. POST /api/users/{id}/disable with an admin API key to set is_disabled=true.
3. Optionally POST /api/users/{id}/regenerate_api_key to invalidate their API key immediately.

Watch out for: Disabling does not remove the user from groups or revoke existing query/dashboard permissions retroactively. Review shared resources separately.

Sync user list to an external directory

1. GET /api/users with an admin API key to retrieve all users.
2. Compare returned list (email, is_disabled, groups) against the external directory.
3. For missing users, POST /api/users to create them.
4. For users present in Redash but removed from the directory, POST /api/users/{id}/disable.

Watch out for: No pagination or delta/incremental endpoint exists; the full user list is fetched on every sync. For large orgs this may be slow. No webhook exists to trigger real-time sync.

The primary integration risk is the lack of pagination on GET /api/users: all users are returned in one response with no cursor, offset, or Link header. This is acceptable at small scale but becomes a latency and memory concern as the user base grows, and there is no documented plan to add pagination.

A second caveat is the re-enable endpoint: DELETE /api/users/{id}/disable re-enables an account - the DELETE method on a /disable sub-resource is counter-intuitive and easy to misread as a permanent delete operation.

Finally, because there is no webhook or event stream for user lifecycle changes, any integration that needs near-real-time sync must poll; missed deprovisioning events between cycles represent a real access-control gap in environments with compliance requirements.