Skip to main content
The auth:* commands manage the credentials the CLI uses to talk to the API. Credentials are stored locally in ~/.so-me/config.json (or ~/.so-me-dev/config.json for the so-me-dev binary).
Every command accepts the global flags --api-key <key>, --api-url <url>, --json (default), --table, and --verbose. The SOME_API_KEY and SOME_API_URL environment variables take precedence over stored credentials. See the CLI Overview for details.

​
auth:login

Authenticate with the API. You can provide an API key directly, or omit it to start browser-approved device provisioning. The Auth.md guide documents the device endpoints and the separate MCP OAuth flow.

​
API key login

When you pass --api-key, the CLI saves the key to local config (along with --api-url if you also set that global flag) and exits without contacting the server.
Output
You can also point at a custom API URL while saving the key:
API key authentication is recommended for scripts and CI/CD. As an alternative to storing the key, set the SOME_API_KEY environment variable.

​
Browser-approved device provisioning

When --api-key is omitted, the CLI starts a device authorization workflow using /auth/device/code and /auth/device/token. These JSON endpoints provision an API key after user approval; they are separate from the MCP OAuth token endpoint:
1

Request a device code

The CLI requests a device code from the API and prints a verification URL plus a one-time user code. It also reports how many minutes the code stays valid.
2

Open the URL and enter the code

The CLI attempts to open your browser automatically (best-effort). Open the printed URL manually if it doesn’t, then enter the displayed code.
3

Wait for authorization

The CLI polls the API while you authorize in the browser. Once approved, it confirms the authorized email and saves the generated API key automatically.
Output
If the device flow succeeds but your plan can’t generate an API key, the CLI prints a warning instead. API access requires the Standard, Advanced, or Lifetime plan. Create a key manually and run so-me auth:login --api-key <key> to finish.
The device flow exits non-zero if the code expires or authorization times out before you complete it. Re-run so-me auth:login to start over.

​
auth:status

Show the current authentication status, including the masked API key and configured API URL. This is a local-only check — it reads stored config and does not hit the server.
Output
The Workspace line is shown only when a default workspace is configured. If no credentials are stored, the command reports that you’re not authenticated and points you to auth:login.
Output (not authenticated)

​
auth:whoami

Verify the current API key against the server and print the authenticated user and organization. Unlike auth:status, which only reads local config, this command hits the API (/v1/settings/profile and /v1/settings/organization) and fails fast if the key has been revoked.
Examples
The result is an object combining both responses under user and organization keys:

​
auth:logout

Remove stored credentials by deleting the local config file.
Output