The Arize REST API provides endpoints for managing access control programmatically. Use these endpoints to automate role assignment, manage project restrictions, and integrate RBAC into your workflows.Documentation Index
Fetch the complete documentation index at: https://arize-ax.mintlify.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
These endpoints are currently in Alpha. Breaking changes are possible. See API Version Stages for details.
Authentication
All RBAC endpoints require Bearer token authentication:Key Concepts
Permission hierarchy
Arize AX uses a hierarchical RBAC model: Account → Organization → Space → Project. Permissions granted at a higher level flow down to resources below it. When a project is restricted, that inheritance is cut off — only users with an explicit role binding on that project can access it.Permission strings
Each permission follows the{RESOURCE}_{ACTION} pattern, for example DATASET_CREATE or PROJECT_READ. When building a custom role, you specify which permissions to grant. To discover available permissions, call GET /v2/roles?is_predefined=true and inspect the permissions arrays on predefined roles, or refer to the interactive API documentation for the complete list.
Predefined vs. custom roles
Predefined roles are built-in system roles (e.g., Admin, Member, Read-only). They cannot be modified or deleted. Custom roles are account-scoped, user-defined roles that can hold any combination of permissions. See Custom Roles for conceptual details.Role binding uniqueness
A user can have at most one role binding per resource. To change a user’s role, update the existing binding — do not delete and recreate it.Privilege escalation prevention
When creating service keys or assigning roles, you can only assign roles at or below your own privilege level.Roles
Manage custom and predefined roles for your account.| Method | Path | Description |
|---|---|---|
GET | /v2/roles | List all roles (custom and predefined) |
POST | /v2/roles | Create a custom role |
GET | /v2/roles/{role_id} | Get a role by ID |
PATCH | /v2/roles/{role_id} | Update a custom role |
DELETE | /v2/roles/{role_id} | Delete a custom role |
Predefined roles (e.g., Admin, Member, Read-only) cannot be updated or deleted.
List roles
is_predefined=true or is_predefined=false to see only built-in or custom roles. Responses are paginated — use limit and cursor parameters for large role lists.
Get a role
Create a custom role
Update a custom role
403 Forbidden.
Delete a custom role
Role Bindings
Assign roles to users on specific resources (spaces or projects).| Method | Path | Description |
|---|---|---|
POST | /v2/role-bindings | Assign a role to a user on a space or project |
GET | /v2/role-bindings/{binding_id} | Get a role binding by ID |
PATCH | /v2/role-bindings/{binding_id} | Update the role in a binding |
DELETE | /v2/role-bindings/{binding_id} | Remove a role binding |
Each user can have one role binding per resource. Attempting to create a duplicate binding returns a
409 Conflict error.Assign a role
Theresource_type field accepts SPACE or PROJECT.
Get a role binding
Update a role binding
To change the role assigned to a user, update the binding with a newrole_id:
role_id can be updated. The user, resource type, and resource cannot be changed — delete and recreate the binding instead.
Delete a role binding
Resource Restrictions
Mark projects as restricted so only users with explicit role bindings can access them.| Method | Path | Description |
|---|---|---|
POST | /v2/resource-restrictions | Restrict a project |
DELETE | /v2/resource-restrictions/{resource_id} | Remove restriction from a project |
Currently, only projects can be restricted. Support for additional resource types is planned.
Restrict a project
Remove a restriction
Schema Reference
Role
| Field | Type | Constraints |
|---|---|---|
id | string | Read-only |
name | string | Required, max 255 chars, unique within account |
description | string | Optional, max 1000 chars |
permissions | string[] | Required on create, min 1 item |
is_predefined | boolean | true = system role (immutable) |
created_at | datetime | Read-only |
updated_at | datetime | Read-only |
RoleBinding
| Field | Type | Constraints |
|---|---|---|
id | string | Read-only |
role_id | string | Required; only mutable field on PATCH |
user_id | string | Required; immutable after creation |
resource_type | string | SPACE or PROJECT; immutable after creation |
resource_id | string | Required; immutable after creation |
created_at | datetime | Read-only |
updated_at | datetime | Read-only |
ResourceRestriction
| Field | Type | Constraints |
|---|---|---|
resource_type | string | Always PROJECT |
resource_id | string | Required |
created_at | datetime | Read-only |
Common Workflows
Onboard a team member with scoped project access
- Restrict the project (if not already restricted):
POST /v2/resource-restrictionswith the project ID. - Create a role binding for the user:
POST /v2/role-bindingswith the user ID, a role ID (e.g., Member), and the project ID.
Create a least-privilege custom role and assign it
- Identify the permissions your use case requires — call
GET /v2/roles?is_predefined=trueto inspect what permissions predefined roles use, or see the interactive API documentation for the full list. - Create a custom role with only those permissions:
POST /v2/roles - Restrict the target project so access is opt-in:
POST /v2/resource-restrictions - Bind the role to the user on that project:
POST /v2/role-bindings
Rotate a user’s role on a project
- Find the existing binding ID (use your own records or
GET /v2/role-bindings/<id>). - Update the binding with the new role:
PATCH /v2/role-bindings/<binding-id>with{ "role_id": "<new-role-id>" }
Audit roles and access
- List all custom roles:
GET /v2/roles?is_predefined=false - List predefined roles:
GET /v2/roles?is_predefined=true - Inspect a specific binding:
GET /v2/role-bindings/<binding-id>