Authentication

The CLI never asks for your email codes. You approve it from the dashboard, where you're already signed in, and it gets a token of its own.

Logging in

Terminal

hiraiship login

Output

ℹ Your one-time code: WDJB-MJHT
  Approve it at https://app.hiraiship.com/device?user_code=WDJBMJHT
  (opened in your browser — or visit the URL above)
  Waiting for approval… (expires in 10 min, Ctrl-C to cancel)
✔ Logged in as you@example.com (workspace you)

The CLI asks Hiraiship for a one-time code and opens the approval page in your browser.
You sign in if needed (with your authenticator code too if two-factor is on), check that the code matches the one in your terminal, and approve.
The CLI receives its token and stores it.

On a machine without a browser, a server over SSH for instance, use --no-browser and open the URL on any device.

Where the token is stored

System	File
macOS, Linux	`~/.config/hiraiship/credentials.json`, or under `$XDG_CONFIG_HOME`
Windows	`%APPDATA%\hiraiship\credentials.json`

The file is readable by your user only. It holds one login per Hiraiship API URL, so a staging API and production don't overwrite each other.

Treat the token like a password

A login token acts as you, with your role in each of your workspaces. Don't commit the file, and don't share the token. hiraiship logout revokes it.

Which credentials are used

For each command, the first one set:

--token <token>;
the HIRAISHIP_TOKEN environment variable;
the stored login for the API URL.

--token and HIRAISHIP_TOKEN accept a login token or a workspace API key (hsk_…).

In CI

Use a workspace API key rather than your own login: it belongs to the workspace, has only the role you give it, and can be revoked alone. Owners and admins create them in the workspace's Settings → API keys; a key with the developer role can deploy.

Set it as HIRAISHIP_TOKEN in your CI's secrets. See CI/CD.

The same key works over HTTP, without the CLI: roles and what a key can't do are on the API's Authentication page.