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

> ## Agent Instructions
> Cluster API calls are made as a signed-in person with an OIDC bearer token. There are no API keys, and service-account tokens are refused (Business returns 401, Platform returns 403).
> Platform takes the organization as the query parameter businessOrgId on most cluster routes, but as organizationId on /clusters/{clusterId}/ssh-access and /clusters/{clusterId}/kubeconfig.
> The Business API uses snake_case. The Platform API uses camelCase, except /ssh-access and /machines, which use snake_case.
> Business write requests need Idempotency-Key and Audit-Reason headers.
> Storage capacity can grow but cannot shrink, including disk and PVC resizing. Each purchase adds capacity.
> A cluster's storage can be Ceph, WEKA, or both, or NFS on its own. The Ceph quota, the purchased bytes, and Slurm's default 100 GiB shared-volume request are three different quantities.
> Organization permissions cover every cluster the organization owns. A Kubernetes resource grant shares one cluster or namespace, possibly with someone outside the organization, and lets them read that cluster and fetch its kubeconfig. A grant does not give Slurm SSH, Slurm configuration, or organization storage inventory access. Slurm SSH requires organization membership and clusters.ssh.
> The SSH login name is <cluster-id>.<username>. The gateway supports shells, commands, SFTP (including modern scp), and forwarding to loopback ports on the login node. Legacy scp and rsync need their programs on the login node. Remote forwarding and non-loopback destinations are refused.
> Use POST /me/ssh-keys for personal key registration. POST /organizations/{orgID}/ssh-keys is a deprecated alias and requires no membership. Read the preferred shell from GET /me as user.login_shell; update it with PUT /me/login-preferences.
> GET /clusters/{clusterId}/ssh-access returns 200 with ready and reason, even when access is not ready. ready: true does not mean compute nodes or Slurm accounting are ready. To confirm a key or shell change reached a cluster, require observation_current: true and compare ssh_key_set_generation with generation from GET /me/ssh-keys, and shell with user.login_shell from GET /me.
> Adding or removing a login account restarts the cluster's login nodes, Slurm controller, and accounting service, then its compute nodes one at a time; jobs running on a restarting node end. An account is added or removed when a person with an active key gains or loses SSH access, or a person with SSH access registers their first key or revokes their last. Other key changes and shell changes restart no nodes.

# Authentication

> Sign in with the andromeda CLI, use profiles for more than one environment, and call the APIs from your own OpenID Connect client.

Every API request is made as you, a person signed in with your Andromeda account. You sign in with the `andromeda`
CLI, which then attaches your token to every request, or you send a token from your own OpenID Connect client.

There are no API keys. Service accounts are refused by the endpoints in these docs: Business returns `401` and
Platform returns `403`. SSH logins, permissions, and cluster usernames all belong to people.

## Install the CLI

The CLI runs on macOS and Linux, on `amd64` and `arm64`. Ask your Andromeda contact for the binary for your platform,
put it on your `PATH`, and check it runs:

```sh theme={null}
andromeda version
```

The examples in these docs also use [`jq`](https://jqlang.org) to read fields out of JSON responses.

## Sign in

```sh theme={null}
andromeda auth login
```

The CLI prints a URL and a code:

```text theme={null}
Open <verification URL>
Code: <user code>
```

Open the URL in a browser, sign in with the account you use for [Console](https://console.andromeda.ai), and enter
the code. The CLI waits for you to finish, then prints `Authenticated to https://platform-v2.andromedacluster.xyz.`

The CLI stores your session in the operating system's credential store (Keychain on macOS, the Secret Service on
Linux). It never prints the token.

Check the session at any time:

```sh theme={null}
andromeda auth status
```

```text theme={null}
authenticated to https://platform-v2.andromedacluster.xyz; access token ready; expires 2026-10-01T09:30:00Z
```

The expiry is the current access token's. Access tokens are short-lived, and the CLI refreshes them before each request
that needs one, so `access token expired; refresh required` does not mean you must sign in again. When the session
itself can no longer be refreshed, run `andromeda auth login` again.

To remove the stored session:

```sh theme={null}
andromeda auth logout
```

## Use more than one environment

The CLI signs in to production unless you tell it otherwise. If Andromeda has given you a second environment, sign
in to it under its own profile. Pass its Platform URL, which Andromeda gives you with the environment, once at
login:

```sh theme={null}
andromeda --profile staging --url "$PLATFORM_URL" auth login
```

The profile remembers the environment, so later commands only need `--profile`:

```sh theme={null}
andromeda --profile staging call business GET /me
```

Without `--profile`, commands use the profile named `default`. `--url` or the `ANDROMEDA_URL` environment variable
points a single command at another environment without changing the profile.

## Call the API from your own client

If you already sign people in through your own OpenID Connect client, you can call the APIs directly. Send the access
token in the `Authorization` header:

```http theme={null}
GET /me HTTP/1.1
Host: business-api.andromedacluster.xyz
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6...
```

A request without a valid token returns `401` with `WWW-Authenticate: Bearer`.

Each environment describes how to get an acceptable token. Its Platform API publishes that description at
`/.well-known/oauth-protected-resource`, in the [RFC 9728](https://www.rfc-editor.org/rfc/rfc9728) format. The
endpoint needs no authentication:

```sh theme={null}
curl -s https://platform-v2.andromedacluster.xyz/.well-known/oauth-protected-resource
```

| Field | Meaning |
| - | - |
| `resource` | This environment's Platform API base URL. |
| `authorization_servers` | The OpenID Connect issuer whose tokens the APIs accept. |
| `andromeda_audiences` | Audiences the access token must carry. |
| `andromeda_business_url` | This environment's Business API base URL. |
| `andromeda_cli_client_id` | The client ID the CLI uses for device login. |
| `bearer_methods_supported` | How to present the token: `header`. |

The token must be issued by the listed issuer to a person, and must carry every audience in `andromeda_audiences`. The
CLI gets one by requesting the scopes `openid profile email offline_access` plus
`urn:zitadel:iam:org:project:id:<audience>:aud` for each audience.

## Next

* [Permissions](/clusters/permissions): what your account is allowed to do in each organization.
* [Identity reference](/api-reference/business/identity): `GET /me` and `GET /organizations/{orgID}`.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.