Skip to main content
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.
OperationHTTP MethodTypical PathDescription
ListGET/v2/{resource}Returns a paginated list of resources, often with filtering or sorting options.
CreatePOST/v2/{resource}Creates a new resource. The request body includes the required fields; the response returns the newly created object.
ReadGET/v2/{resource}/{id}Retrieves a single resource by its unique identifier.
UpdatePATCH or PUT/v2/{resource}/{id}Updates part or all of an existing resource. Some endpoints support versioned or in-place updates.
DeleteDELETE/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:
StagePurposeReliabilityRecommended for
AlphaEarly development & experimentationExperimental: Breaking changes expectedDevelopers exploring new capabilities
BetaValidation & feedback of mostly complete features through real world useMostly stable: minor changes possible, breaking changes rareTeams seeking early access willing tolerate minor instability
StableProduction readyBackwards compatible, no breaking changesAll 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.
EnvironmentBase URLAvailable RegionsNotes
Globalhttps://api.arize.com/v2N/ARecommended for most users. Routes automatically to the nearest global endpoint.
Regionalhttps://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}/v2CustomFor 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: 
{
  "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. 
{
  "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?