Skip to main content
hiloop commands start from one API URL. A context gives that URL a name, stores credentials for that environment, and lets the CLI discover sibling services such as telemetry ingest.

​
The built-in context

The built-in context is prod, which points at the hosted hiloop API (api.hiloop.ai). While the hosted edge is being finalized it is not live yet, so commands that fall back to it fail with no API URL is configured — set up a context for your deployment first.

​
Add an environment

Create a context for any deployment with an API edge, select it, and sign in:
Then run commands normally:
For one command, use --context instead of switching the default:

​
Remove a context

Delete a context you no longer need:
Removing the active context switches the CLI back to the built-in prod context. The built-in prod context cannot be removed.

​
How service discovery works

The CLI fetches the active API’s public discovery document:
That document contains non-secret URLs such as the telemetry gateway and login entry point for that deployment. The CLI caches those values briefly and refetches them when needed. This keeps the login experience the same across hosted and self-hosted deployments: the CLI starts from the API URL, then follows the login URLs advertised by that deployment.

​
Override service URLs

Most deployments should not need service URL overrides. If your deployment cannot expose discovery yet, store explicit URLs on the context:
Precedence is:
  1. Command flag or environment variable.
  2. Context override.
  3. API service discovery.
  4. Built-in default, when the command has one.

​
Automation

For CI and other automation, provide an API key with the command environment:
You can also store an API key for the selected context:
The CLI stores credentials using platform-appropriate storage and scopes them to the API URL, so a credential for one context is not reused against another context.