Credentials & configuration

Two credential kinds

They are not interchangeable.

Kind	How	Reach
API key (rk_…)	rtz login --token or RTZ_TOKEN	Must carry the api:read scope. Authorizes exactly as the user who created it does, for every cluster-scoped command. Carries no role, so org and user administration is out of reach by design.
Browser sign-in	rtz login	Full role parity, including administration. The redirect returns to a listener on 127.0.0.1 that the command opens; over SSH, --no-browser prints the URL and the exact ssh -L line to forward the port.

Caution

An ingest key will not work. ingest:* scopes authorize the ingest gateway, not this API. Create a separate key with api:read.

Credentials go to the OS keychain when one is reachable, and to a 0600 file otherwise — the normal case on a headless Linux box with no D-Bus session.

Contexts

Contexts work like kubectl’s: a named target holding an API URL, an org, and a cluster.

rtz config get-contexts
rtz config use-context prod
rtz config path

Precedence is flag → environment → context, so a --flag never loses to a config file.

Flag	Env	Meaning
--context	RTZ_CONTEXT	Which stored context to use
--api	RTZ_API	Backend base URL
--org	RTZ_ORG	Organization id
--cluster	RTZ_CLUSTER	Cluster id
—	RTZ_TOKEN	API key, winning over anything stored
—	RTZ_CONFIG	Config file path