Overview

Welcome to the Arize REST API. This API is the programmatic interface to the Arize platform—designed so that every capability we offer can be discovered, automated, and integrated into your workflows. While the current release exposes core resources (e.g., datasets and experiments), our long-term vision is that the entire product line will be accessible and controllable via this API.

The API follows modern REST conventions with JSON payloads, standard HTTP status codes, cursor-based pagination, structured error responses, and sensible rate limits. It is versioned to preserve backwards compatibility as we evolve (e.g., /v2/...) and is available globally as well as with regional endpoints. Authentication is simple and secure via API keys, and first-party SDKs provide idiomatic access for popular languages.

Use this API to:

• Integrate Arize capabilities into CI/CD, data pipelines, and internal tools

• Automate creation, management, and analysis of resources across your account

• Build custom workflows and dashboards on top of the Arize platform primitives

API Design Principles

The Arize REST API follows a CRUDL design pattern — Create, Read, Update, Delete, and List — providing a predictable, consistent interface across all resources. This means that once you learn how to interact with one resource, you’ll know how to interact with others.

Operation	HTTP Method	Typical Path	Description
List	GET	/v2/{resource}	Returns a paginated list of resources, often with filtering or sorting options.
Create	POST	/v2/{resource}	Creates a new resource. The request body includes the required fields; the response returns the newly created object.
Read	GET	/v2/{resource}/{id}	Retrieves a single resource by its unique identifier.
Update	PATCH or PUT	/v2/{resource}/{id}	Updates part or all of an existing resource. Some endpoints support versioned or in-place updates.
Delete	DELETE	/v2/{resource}/{id}	Permanently removes a resource. Deletes are irreversible.

Why CRUDL?

• Predictable: Every resource behaves consistently — you always know which verbs to use.

• Composable: Enables automation and integration with existing REST-friendly tooling.

• Extensible: New resources can adopt the same verbs and structure without breaking changes.

• Safe and versioned: Operations that modify data are versioned and validated to preserve data integrity.

API Version Stages

Our API evolves through three release stages — Alpha, Beta, and Stable — to introduce new functionality safely, with clear expectations for reliability and frequency of change. Each endpoint includes a release stage label that indicates its level of stability:

Stage	Purpose	Reliability	Recommended for
Alpha	Early development & experimentation	Experimental: Breaking changes expected	Developers exploring new capabilities
Beta	Validation & feedback of mostly complete features through real world use	Mostly stable: minor changes possible, breaking changes rare	Teams seeking early access willing tolerate minor instability
Stable	Production ready	Backwards compatible, no breaking changes	All production integrations

API Hosts & Regions

Arize operates in multiple environments to support the deployment needs of enterprises. You can send requests to the global API for standard usage or to a regional endpoint when compliance and data residency are required. Enterprise customers may also configure custom hosts for private or on-premise installations.

Environment	Base URL	Available Regions	Notes
Global	https://api.arize.com/v2	N/A	Recommended for most users. Routes automatically to the nearest global endpoint.
Regional	https://api.{region}.arize.com/v2	us-central-1a us-east-1b ca-central-1a eu-west-1a	Use for compliance and data residency requirements.
Custom Host	{scheme}://{host}/v2	Custom	For on-premise, private cloud, or enterprise environments.

Authentication

Most endpoints require authentication with an API key, sent in the HTTP request header:

Authorization: Bearer <api-key>

The API works with both User Keys and Service Keys interchangeably.

Response Format

All Arize API endpoints return structured JSON responses designed to be predictable, human-readable, and machine-parsable. Each response falls into one of two categories: success responses or error responses.

Success Responses

Successful responses (2xx status codes) return the requested data in JSON format.

Example:

Response to Get Dataset by ID

{
  "id": "RGF0YXDk3MFNldoDzMTc3MpWbQ==",
  "name": "dataset name",
  "spaceId": "U3BhYiRnVM2U6MTp",
  "createdAt": "2025-10-08T03:24:38.014847Z",
  "updatedAt": "2025-10-08T03:24:38.014847Z",
  "versions": [
    {
      "id": "RGF0Npb246MzE4NDg5OkhYXNldFZlcnQQ00=",
      "name": "dataset version name",
      "datasetId": "RGF0YXDk3MFNldoDzMTc3MpWbQ==",
      "createdAt": "2025-10-08T03:24:38.060322Z",
      "updatedAt": "2025-10-08T03:24:38.014847Z"
    }
  ]
}

Pagination

Most list endpoints implement cursor-based pagination, while others include pagination fields for forward compatibility. This ensures client applications remain stable as pagination support expands over time.

• Use the limit query parameter to control the number of items per request.

• When more data is available, the response includes:

  • hasMore: true — indicates additional pages exist.

  • nextCursor — an opaque string token used to fetch the next page.

The few endpoints that don't have pagination implemented yet will return hasMore accurately but the nextCursor will always be missing.

Response to List Datasets

{
  "datasets": [ /* items */ ],
  "pagination": {
    "hasMore": true,
    "nextCursor": "eyJvZmZzZXQiOiIyMDI1LTEw..."
  }
}

Error Responses

Error responses (4xx and 5xx) use the RFC 9457 Problem Details format.

{
  "status": 400,
  "title": "short, human-readable summary of the problem type",
  "detail": "human-readable explanation specific to this occurrence of the problem"
}

Support

Need help integrating the API or running experiments?

• Join our Slack Community

• Email us at [e-mail]