Skip to main content

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.

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.
These endpoints are currently in Alpha. Breaking changes are possible. See API Version Stages for details.

Authentication

All RBAC endpoints require Bearer token authentication:
Authorization: Bearer <api-key>
Both User Keys and Service Keys are supported. See Authentication for details.

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.
MethodPathDescription
GET/v2/rolesList all roles (custom and predefined)
POST/v2/rolesCreate 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

curl https://api.arize.com/v2/roles \
  -H "Authorization: Bearer <api-key>"
You can filter by 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.
{
  "roles": [
    {
      "id": "Rol001",
      "name": "Dataset Manager",
      "description": "Can manage datasets and run experiments",
      "permissions": [
        "DATASET_READ",
        "DATASET_CREATE",
        "DATASET_UPDATE",
        "DATASET_DELETE",
        "EXPERIMENT_READ",
        "EXPERIMENT_CREATE"
      ],
      "is_predefined": false,
      "created_at": "2024-06-01T10:00:00Z",
      "updated_at": "2024-06-01T10:00:00Z"
    }
  ],
  "pagination": {
    "has_more": false,
    "next_cursor": null
  }
}

Get a role

curl https://api.arize.com/v2/roles/<role-id> \
  -H "Authorization: Bearer <api-key>"

Create a custom role

curl -X POST https://api.arize.com/v2/roles \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Dataset Manager",
    "description": "Can manage datasets and run experiments",
    "permissions": [
      "DATASET_READ",
      "DATASET_CREATE",
      "DATASET_UPDATE",
      "DATASET_DELETE",
      "DATASET_EXAMPLE_READ",
      "DATASET_EXAMPLE_CREATE",
      "EXPERIMENT_READ",
      "EXPERIMENT_CREATE"
    ]
  }'
To discover available permission values, 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.

Update a custom role

curl -X PATCH https://api.arize.com/v2/roles/<role-id> \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "permissions": [
      "DATASET_READ",
      "DATASET_CREATE",
      "EXPERIMENT_READ"
    ]
  }'
When updating permissions, the provided list replaces the entire set — it is not a merge. Include all permissions you want the role to have.
Predefined roles cannot be updated. Attempting to do so returns a 403 Forbidden.

Delete a custom role

curl -X DELETE https://api.arize.com/v2/roles/<role-id> \
  -H "Authorization: Bearer <api-key>"
Roles are soft-deleted. Predefined roles cannot be deleted.

Role Bindings

Assign roles to users on specific resources (spaces or projects).
MethodPathDescription
POST/v2/role-bindingsAssign 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

The resource_type field accepts SPACE or PROJECT.
curl -X POST https://api.arize.com/v2/role-bindings \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "role_id": "<role-id>",
    "user_id": "<user-id>",
    "resource_type": "PROJECT",
    "resource_id": "<project-id>"
  }'
{
  "id": "Rbd001",
  "role_id": "<role-id>",
  "user_id": "<user-id>",
  "resource_type": "PROJECT",
  "resource_id": "<project-id>",
  "created_at": "2024-06-01T10:00:00Z",
  "updated_at": "2024-06-01T10:00:00Z"
}

Get a role binding

curl https://api.arize.com/v2/role-bindings/<binding-id> \
  -H "Authorization: Bearer <api-key>"

Update a role binding

To change the role assigned to a user, update the binding with a new role_id:
curl -X PATCH https://api.arize.com/v2/role-bindings/<binding-id> \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{
    "role_id": "<new-role-id>"
  }'
Only the role_id can be updated. The user, resource type, and resource cannot be changed — delete and recreate the binding instead.

Delete a role binding

curl -X DELETE https://api.arize.com/v2/role-bindings/<binding-id> \
  -H "Authorization: Bearer <api-key>"

Resource Restrictions

Mark projects as restricted so only users with explicit role bindings can access them.
MethodPathDescription
POST/v2/resource-restrictionsRestrict 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

curl -X POST https://api.arize.com/v2/resource-restrictions \
  -H "Authorization: Bearer <api-key>" \
  -H "Content-Type: application/json" \
  -d '{"resource_id": "<project-id>"}'
This operation is idempotent — restricting an already-restricted project returns successfully.

Remove a restriction

curl -X DELETE https://api.arize.com/v2/resource-restrictions/<project-id> \
  -H "Authorization: Bearer <api-key>"
See Project-Level Restrictions for details on how restrictions affect access.

Schema Reference

Role

FieldTypeConstraints
idstringRead-only
namestringRequired, max 255 chars, unique within account
descriptionstringOptional, max 1000 chars
permissionsstring[]Required on create, min 1 item
is_predefinedbooleantrue = system role (immutable)
created_atdatetimeRead-only
updated_atdatetimeRead-only

RoleBinding

FieldTypeConstraints
idstringRead-only
role_idstringRequired; only mutable field on PATCH
user_idstringRequired; immutable after creation
resource_typestringSPACE or PROJECT; immutable after creation
resource_idstringRequired; immutable after creation
created_atdatetimeRead-only
updated_atdatetimeRead-only

ResourceRestriction

FieldTypeConstraints
resource_typestringAlways PROJECT
resource_idstringRequired
created_atdatetimeRead-only

Common Workflows

Onboard a team member with scoped project access

  1. Restrict the project (if not already restricted): POST /v2/resource-restrictions with the project ID.
  2. Create a role binding for the user: POST /v2/role-bindings with the user ID, a role ID (e.g., Member), and the project ID.

Create a least-privilege custom role and assign it

  1. Identify the permissions your use case requires — call GET /v2/roles?is_predefined=true to inspect what permissions predefined roles use, or see the interactive API documentation for the full list.
  2. Create a custom role with only those permissions: POST /v2/roles
  3. Restrict the target project so access is opt-in: POST /v2/resource-restrictions
  4. Bind the role to the user on that project: POST /v2/role-bindings

Rotate a user’s role on a project

  1. Find the existing binding ID (use your own records or GET /v2/role-bindings/<id>).
  2. Update the binding with the new role: PATCH /v2/role-bindings/<binding-id> with { "role_id": "<new-role-id>" }

Audit roles and access

  1. List all custom roles: GET /v2/roles?is_predefined=false
  2. List predefined roles: GET /v2/roles?is_predefined=true
  3. Inspect a specific binding: GET /v2/role-bindings/<binding-id>

Full API Reference

For complete request and response schemas, see the interactive API documentation.
For additional support, join the Arize Community Slack.