> ## Documentation Index
> Fetch the complete documentation index at: https://ekso.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Ekso CLI

> Drive Ekso from the command line — automation, scripting, CI integrations, and one-off admin tasks.

## Overview

The Ekso CLI is a single binary, `ekso`, that exposes every public Ekso API operation as a curated command. It speaks the same protocol as the [SDK](/sdk/overview) but is shaped for shells, scripts, and CI — not application code.

Reach for the CLI when you want to:

* Drive Ekso from a terminal during admin work, debugging, or one-off cleanup.
* Wire Ekso into shell pipelines (`ekso item list --format json | jq ...`).
* Automate from CI/CD without writing a .NET app — issue an API key, set `EKSO_API_KEY`, run `ekso ...`.
* Onboard new installs by replaying a folder of curated payloads through `ekso ... --data @file.json`.

For programmatic embedding inside a .NET application, prefer the [SDK](/sdk/overview).

## What's in the box

The CLI groups operations into 36 top-level **branches** (one per resource — `item`, `board`, `field`, `docs`, `file`, `auth`, …). Each branch carries verbs scoped to that resource (`ekso item list`, `ekso item create`, `ekso field create-date`).

Every command shares a global flag surface: `--url`, `--api-key`, `--format`, `--quiet`, `--verbose`, `--no-color`, `--timeout`. Anything you can pass on the command line you can also set via an `EKSO_*` environment variable. See [Configuration](/cli/configuration) for the full list.

Output is structured: JSON by default, with table / YAML / JSONL formats available via `--format`. Every command returns a POSIX exit code that maps to a specific failure shape (auth, validation, not-found, rate-limit, etc.) so shell pipelines can branch on the cause.

## Authentication paths

Two ways to authenticate:

* **`ekso auth login`** — interactive OAuth 2.0 device-flow. Best for humans; tokens auto-refresh and are cached per install URL.
* **`--api-key` flag or `EKSO_API_KEY` env var** — non-interactive bearer-token auth. Best for CI, agents, and headless automation. Mint keys via the admin surface.

The CLI authenticates as a CLI/SDK client (the JWT carries an `EksoClient=Cli` claim, API keys resolve to `Sdk`), which the backend uses to gate operations that should not be scriptable — for example, system-field updates are rejected from the CLI but allowed from the webapp. See [CLI/SDK marker](/sdk/cli-sdk-marker) for the full semantics.

## Quick taste

```bash theme={null}
# Install
dotnet tool install -g Ekso.Cli

# Authenticate (opens a browser tab to approve the device code)
ekso auth login --url https://ekso.acme.com

# List your items
ekso item list --url https://ekso.acme.com

# Create a custom field via the curated typed surface
ekso field create-text --name "Customer Reference" --maximum 64 --url https://ekso.acme.com
```

## Where to next

* **[Installation](/cli/installation)** — install the CLI and check the version.
* **[Authentication](/cli/authentication)** — device-flow login, API keys, precedence rules.
* **[Configuration](/cli/configuration)** — flag/env-var reference, output formats, exit codes.
* **[Branches](/cli/branches)** — every command, grouped by resource.
* **[Migrate](/cli/migrate/overview)** — switching to Ekso from Jira, Linear, Azure DevOps, Zendesk, or Countersoft Gemini.

The CLI talks to your Ekso install by URL — there is no concept of "tenant" in the self-host model. Whatever `PublicUrl` you set during the `/startup` wizard is what you pass via `--url` (or `EKSO_URL`).

* **[API Reference](/api-reference/introduction)** — the underlying HTTP surface every CLI command calls.