1ctl token

1ctl token manages API tokens — the long-lived credentials you use for programmatic access to Satusky. Unlike a browser session, tokens don’t expire unless you explicitly set an expiry or revoke them. They’re the right tool for CI/CD pipelines, deployment scripts, and any automation that needs to talk to the Satusky API.

Every request the CLI (or your own code) makes to https://api.satusky.com/v1/cli is authenticated by a token in the x-satusky-api-key header. The backend validates it against the api_tokens table on every request — there is no session cache. A disabled or deleted token is rejected immediately.

The raw token value is only returned once, at creation time. The backend stores only a hash. If you lose it, you cannot recover it — create a new one and revoke the old one.

Usage

1ctl token

Flags

Flag	Type	Required	Default	Description
--help, -h	boolean	No	—	Show help

Subcommands

Command	Description
list	List API tokens
create	Create a new API token
get	Get token details
enable	Enable a token
disable	Disable a token
delete	Delete a token

Practical patterns

CI/CD pipelines. Create a dedicated token per pipeline with a 90-day expiry. Store it as a CI secret (SATUSKY_API_KEY). Rotate it by creating a new token, updating the secret, then deleting the old one — with no downtime between steps.

# In GitHub Actions
- name: Deploy
  env:
    SATUSKY_API_KEY: ${{ secrets.SATUSKY_API_KEY }}
  run: 1ctl deploy

Token hygiene. Run 1ctl token list periodically. Disable any token you don’t recognise, investigate, then delete it if it wasn’t yours. Tokens with status disabled can always be cleaned up without operational impact.

Security incident. If a token is compromised, delete it — not just disable it. Then rotate any credentials the compromised token had access to. If you suspect broader access, also run 1ctl user sessions revoke to terminate active browser sessions.