Authentication

Sign in to the revenexx CLI with a token, understand how credentials resolve from flags, environment, and config files, and select the tenant your commands apply to.

The CLI authenticates two ways: an interactive browser sign-in for working at a terminal, and a gateway API key for CI and automation. Both end the same way — a validated session saved to disk so later commands don't have to repeat it.

Sign in

Run login. With no credential supplied, the CLI opens your browser to sign in with ID, captures the resulting user token, and saves your session to ~/.revenexx/prefs.json.

Shell
revenexx login

If a credential is already present — a --token flag, the REVENEXX_API_KEY environment variable, or a .revenexx.yaml file in the current directory tree — login uses that instead of opening the browser. A supplied key always takes precedence over the interactive flow, which keeps existing setups working unchanged.

For CI and scripts, pass a machine-to-machine API key and tenant directly so nothing needs a browser:

Shell
revenexx login --token <api-key> --tenant <slug>

Both paths talk to https://api.revenexx.com. A browser session sends its user token as Authorization: Bearer <token>; an API key rides as X-Revenexx-Api-Key. Either way the tenant travels as X-Revenexx-Tenant.

Credential resolution order

Any command that needs auth resolves its credentials the same way. The first source that has a value wins:

  1. CLI flag — --token, --endpoint, --tenant
  2. Environment variables — REVENEXX_API_KEY, REVENEXX_API_URL, REVENEXX_TENANT
  3. Project file — the nearest .revenexx.yaml, walking up from the current directory
  4. Global config — ~/.revenexx/prefs.json, written by revenexx login (either a browser session or a saved key)
  5. Built-in default — the endpoint defaults to https://api.revenexx.com

A supplied key (sources 1–3) always wins over a stored browser session. The interactive browser sign-in only kicks in when you run login and none of those credential sources has a value — so CI never opens a browser.

The tenant slug has its own precedence: the --tenant flag, then the value set by tenants use (stored in ~/.revenexx/tenant), then REVENEXX_TENANT, then .revenexx.yaml.

Select a tenant

tenants scopes your commands to one tenant. Set it once and every later command applies there.

Shell
revenexx tenants use <slug>

Don't know your slug? revenexx tenants list shows the tenants your signed-in account can access — read from your browser-session token, no Cockpit visit needed. The line printed right after revenexx login names them too.

use validates the slug against the gateway first — with your API key when one is set, otherwise with your browser session — and rejects a tenant you can't reach. Pass --force to set it anyway.

Check or list what's active:

Shell
revenexx tenants current
revenexx tenants current --check
revenexx tenants list
  • tenants current prints the active slug; --check verifies it against the gateway.
  • tenants list shows the tenants your account can access (from the SSO session) plus every slug this machine knows about — from flags, environment, .revenexx.yaml, the saved slug, and API-key sessions — along with where each came from and whether your current credential can reach it.

What's next

Was this page helpful?