RBAC REST API - Arize AX Docs

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 on predefined roles, call GET /v2/roles?is_predefined=true and inspect the permissions arrays.

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.

User Management

Invite, list, update, and remove users across your account, organizations, and spaces.

Method	Path	Description
`POST`	`/v2/users`	Create a user
`GET`	`/v2/users`	List users
`GET`	`/v2/users/{user_id}`	Get a user
`PATCH`	`/v2/users/{user_id}`	Update a user
`DELETE`	`/v2/users/{user_id}`	Delete a user
`POST`	`/v2/users/{user_id}/resend-invitation`	Resend a user invitation
`POST`	`/v2/users/{user_id}/reset-password`	Trigger a password-reset email for a user
`POST`	`/v2/organizations/{org_id}/users`	Add a user to an organization
`DELETE`	`/v2/organizations/{org_id}/users/{user_id}`	Remove a user from an organization
`POST`	`/v2/spaces/{space_id}/users`	Add a user to a space
`DELETE`	`/v2/spaces/{space_id}/users/{user_id}`	Remove a user from a space

For invite_mode options when creating a user, see Invite a user via API in the Common Workflows section below.

Roles

Manage custom and predefined roles for your account.

Method	Path	Description
`GET`	`/v2/roles`	List roles
`POST`	`/v2/roles`	Create a role
`GET`	`/v2/roles/{role_id}`	Get a role
`PATCH`	`/v2/roles/{role_id}`	Update a role
`DELETE`	`/v2/roles/{role_id}`	Delete a 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 on predefined roles, call GET /v2/roles?is_predefined=true and inspect the permissions arrays.

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).

Method	Path	Description
`POST`	`/v2/role-bindings`	Create a role binding
`GET`	`/v2/role-bindings/{binding_id}`	Get a role binding
`PATCH`	`/v2/role-bindings/{binding_id}`	Update a role binding
`DELETE`	`/v2/role-bindings/{binding_id}`	Delete 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.

Method	Path	Description
`POST`	`/v2/resource-restrictions`	Restrict a resource
`DELETE`	`/v2/resource-restrictions/{resource_id}`	Unrestrict a resource

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

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

Invite a user via API

Use POST /v2/users to invite a user programmatically. The invite_mode field controls how the invited user completes sign-up:

`invite_mode`	Behavior
`email_link`	Sends the user an email with a sign-up link. Default for most accounts.
`temporary_password`	Sends the user a temporary password. Useful when email delivery is restricted.
`none`	No email is sent. Use only when Allow Only SAML Logins is enabled — users log in directly via SSO without a separate sign-up step.

Using invite_mode: none on an account where Allow Only SAML Logins is not enabled will leave the user with no way to complete sign-up.

Onboard a team member with scoped project access

Restrict the project (if not already restricted): POST /v2/resource-restrictions with the project ID.
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

Identify the permissions your use case requires — call GET /v2/roles?is_predefined=true to inspect what permissions predefined roles use.
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>

Full API Reference

For complete request and response schemas, see the API reference:

You can also explore and try out all endpoints interactively at api.arize.com/v2/docs.

For additional support, join the Arize Community Slack.

​Authentication

​Key Concepts

​Permission hierarchy

​Permission strings

​Predefined vs. custom roles

​Role binding uniqueness

​Privilege escalation prevention

​User Management

​Roles

​List roles

​Get a role

​Create a custom role

​Update a custom role

​Delete a custom role

​Role Bindings

​Assign a role

​Get a role binding

​Update a role binding

​Delete a role binding

​Resource Restrictions

​Restrict a project

​Remove a restriction

​Schema Reference

​Role

​RoleBinding

​ResourceRestriction

​Common Workflows

​Invite a user via API

​Onboard a team member with scoped project access

​Create a least-privilege custom role and assign it

​Rotate a user’s role on a project

​Audit roles and access

​Full API Reference

Authentication

Key Concepts

Permission hierarchy

Permission strings

Predefined vs. custom roles

Role binding uniqueness

Privilege escalation prevention

User Management

Roles

List roles

Get a role

Create a custom role

Update a custom role

Delete a custom role

Role Bindings

Assign a role

Get a role binding

Update a role binding

Delete a role binding

Resource Restrictions

Restrict a project

Remove a restriction

Schema Reference

Role

RoleBinding

ResourceRestriction

Common Workflows

Invite a user via API

Onboard a team member with scoped project access

Create a least-privilege custom role and assign it

Rotate a user’s role on a project

Audit roles and access

Full API Reference