SDKs & CLI

The Nexa CLI (nexa) is the supported way to automate the platform from a terminal, a CI job, or an agent tool. It gives you one command surface across every Nexa API — you configure an environment and token once, and the CLI handles the bearer header, environment selection, retries, and output formatting. This page covers installing, authenticating, and using it.

There is no separate published language SDK today. If you need to call the APIs from application code, generate a client from the OpenAPI specs behind the reference docs, or use the CLI as a subprocess.

What the CLI covers

The CLI is domain-oriented: each API is a command group. It wraps nexa-databricks-api, nexa-agents-api, actg-ai, and nexa-orchestration-service.

Group	Example	Covers
`configure`	`nexa configure init`	CLI config and environments
`auth`	`nexa auth check`	Verify credentials
`catalog`	`nexa catalog ...`	Databricks catalog & metadata
`jobs` / `pipelines`	`nexa jobs list`	Job and pipeline orchestration
`statements`	`nexa statements ...`	SQL execution
`lineage`	`nexa lineage ...`	Data lineage
`warehouses` / `workspace`	`nexa warehouses list`	Compute and workspace
`connectors` / `deploy` / `artifacts`	`nexa deploy ...`	Connectors and deployments
`environments`	`nexa environments list`	Deployment environments
`observability` / `dbu-usage`	`nexa dbu-usage ...`	Cost and usage
`agents`	`nexa agents deploy`	Agents API
`actg`	`nexa actg ...`	ACTG-AI jobs
`orchestration`	`nexa orchestration ...`	Orchestration workflows

Run nexa --help for the full list, and nexa <group> --help for a group’s commands.

Install

The CLI is a Poetry-managed Python package. From the nexa-databricks-cli repository:

poetry install
poetry run nexa --help

Once installed you invoke it as nexa (shown below with poetry run where the entry point isn’t on your PATH).

Configure an environment

The CLI stores configuration in ~/.nexa/config.toml, keyed by named environments with one marked active. Each environment records the API URLs for the services and how to find the auth token.

Initialize the config with a default environment:
Terminal window
```
poetry run nexa configure init
```

Point tokens at an environment variable. An environment entry can set token_env_var, and the CLI reads the token from that variable at call time — so secrets never live in the config file. A minimal ~/.nexa/config.toml looks like:

active_environment = "dev"

[environments.dev]
api_url = "https://<your-databricks-api-host>/dbx"
agents_api_url = "https://<your-agents-api-host>"
actg_api_url = "https://<your-actg-host>"
orchestration_api_url = "https://<your-orchestration-host>"
token_env_var = "NEXA_TOKEN"

Export the token the CLI will send (see Authentication for how to obtain one):
Terminal window
```
export NEXA_TOKEN="eyJhbGciOiJIUzI1NiI..."
```

On each request the CLI sends Authorization: Bearer <token> plus an X-Environment-Id header for the selected environment. If no token resolves, it warns and continues unauthenticated — which the API will reject on protected paths.

Verify and use

Check credentials resolve and the API is reachable:
Terminal window
```
poetry run nexa auth check
```
Run a command. Most read commands accept --output/-o to switch between a table and JSON:
Terminal window
```
poetry run nexa environments list
poetry run nexa jobs list --output json
```
Target another environment by activating it (or pass the environment where the command supports it), so a single install can drive dev, staging, and prod.

Databricks
Snowflake

The Databricks command groups (catalog, jobs, pipelines, statements, lineage, warehouses, workspace) map to the Databricks Platform API.

On Snowflake deployments, use the platform-agnostic groups (environments, agents, actg, deploy) and the Snowflake API reference for the catalog and codegen surface. Point api_url at your Snowflake API host.

Output formats

Commands default to a Rich table for humans and accept --output json for scripting. Pipe the JSON form into jq or your CI tooling. Non-zero exit codes signal API or usage errors, so the CLI is safe to gate a pipeline on.

For the token types the CLI accepts, see Authentication; for environments and error conventions, see Core Concepts.