Skip to main content
This page covers Arize AX Python SDK version 8 for on-premise and self-hosted Arize AX. For SDK v7, see On-Premise SDK Usage — Version 7. For an overview of both versions, see On-Premise SDK Usage.

Single Endpoint

With single endpoints, all services are available through a common host address and port:

Example with Arize AX Python SDK v8

Use ArizeClient with single_host so that all SDK endpoints (API, OTLP, and Flight) use the same host. You can omit single_port (default 443). Pass space_id and project_name on each operation (for example, when logging spans or listing datasets).
For single-host deployments you can also set SINGLE_HOST in the environment and construct the client with only single_host.

Example with OTEL traces and GRPC

Example with OTEL traces and HTTP

Example: ML inference logging (same client)

The same ArizeClient is used for ML inference logging. Call client.ml.log() with space_id, model_name, model_type, dataframe, schema, and environment.

Example: Exporting spans (same client)

In SDK v8, export and dataset operations use the same ArizeClient instance. With a single endpoint, no extra configuration is needed.

Example: Datasets and experiments (same client)

The same client is used for datasets and experiments. Create a dataset with name, space_id, and examples (a DataFrame); retrieve it with datasets.get(dataset_id=...).

Four Endpoints

If your deployment is configured with four endpoints, it requires different ingress configurations and host addresses:

Example with Arize AX Python SDK v8

Use ArizeClient with separate hosts for API, OTLP, and Flight when your deployment uses four endpoints. Pass space_id on each operation. You can also use environment variables ARIZE_API_HOST, ARIZE_OTLP_HOST, ARIZE_FLIGHT_HOST, ARIZE_FLIGHT_PORT, and ARIZE_FLIGHT_SCHEME and construct the client with ArizeClient(api_key=API_KEY).

Example with OTEL traces and GRPC

Example with OTEL traces and HTTP


Using an Enterprise-Issued Certificate

If your deployment uses a certificate signed by your own enterprise private CA or a self-signed certificate, follow the relevant instructions below for your deployment type and use case. You can set ARIZE_SSL_CA_CERT to a certificate path (or colon/semicolon-separated list of paths) and, in your code, set REQUESTS_CA_BUNDLE and SSL_CERT_FILE to that bundle before importing arize. To disable verification in development only: ARIZE_REQUEST_VERIFY=false.

Obtaining the Root CA Certificate

First, obtain the root CA certificate that was used to sign your endpoint’s certificate. This root certificate is typically managed by the security team and is common across environments.

Extracting the Certificate (if root CA is not available)

If providing the root certificate doesn’t resolve the issue or is not an option, extract the certificate directly from the endpoint:

Environment-based CA bundle and certificate options

Environment-based CA bundle — Set ARIZE_SSL_CA_CERT to the path to your .crt or .pem file. For multiple certs, use a colon-separated list (Unix) or semicolon-separated (Windows), e.g. ARIZE_SSL_CA_CERT="/path/cert1.crt:/path/cert2.crt". In your code, before importing arize, set REQUESTS_CA_BUNDLE and SSL_CERT_FILE to that path (or to a single merged bundle file). You can merge multiple certs into one bundle and set these env vars so the SDK and OTLP exporter use your CA(s).
  • Temporarily disable certificate validation (not recommended for production): Set ARIZE_REQUEST_VERIFY=false in the environment, or:
  • Provide the root certificate file via client:
    Or use your system CA bundle:
    For four-endpoint deployments, pass the same request_verify value with api_host, otlp_host, and flight_host instead of single_host.

OTEL Traces (GRPC/HTTP)

  • Set the OTEL_EXPORTER_OTLP_CERTIFICATE environment variable to your root certificate:
    Or

Flight (gRPC) connections

When using ArizeClient for export, datasets, or experiments, bulk data may be sent over Arrow Flight (gRPC). If you use a custom or enterprise certificate, set GRPC_DEFAULT_SSL_ROOTS_FILE_PATH so the gRPC layer can verify the server:
  • Set the GRPC_DEFAULT_SSL_ROOTS_FILE_PATH environment variable to your root certificate:
    Or use your system CA bundle: