Skip to main content
Get started
Headless CLIInstall + sign in
Headless CLI

Install + sign in

Install the CLI, add an API key, and confirm your machine can operate the right workspace.

Install the CLI under Bun, authenticate with ALY_API_KEY, pick a transport, verify with whoami.

The CLI lives in the aly-store repo at tools/aly-store-cli.ts. It runs under Bun. There's no separate npm package today — for non-Bun users we publish a Node wrapper.

Bun (recommended)

bash
# 1. Install Bun if you don't have itcurl -fsSL https://bun.sh/install | bash # 2. Clone the repogit clone https://github.com/aly/aly-store.gitcd aly-storebun install # 3. Run the CLIbun tools/aly-store-cli.ts sites list # (Optional) Create a shell aliasecho 'alias aly-store-cli="bun \$HOME/code/aly-store/tools/aly-store-cli.ts"' >> ~/.zshrc

Authenticating

Two options. Pick one.

Env var

bash
export ALY_API_KEY="aly_a8d9...e3c7"aly-store-cli sites list

Flag

bash
aly-store-cli --api-key "aly_a8d9...e3c7" sites list

The env var wins. If both are set, the flag overrides per-invocation but the env stays as the default for unflagged commands.

Picking a transport

Default is MCP. For CI loops, prefer --direct:

bash
aly-store-cli --direct orders list --status pending

Verifying it works

bash
aly-store-cli whoami

Should print the workspace id and the scope set the key carries.

Scopes

Mint a key with the scopes the CLI needs. For most tasks read:sites, read:content, write:content, read:orders, and write:orders are enough. For CI that publishes new products, also include write:media.

One key per environment
Use separate API keys for local development, staging, and production CI. When you suspect a leak, you can revoke a single environment without disrupting the others.

Updating

From inside the repo, git pull && bun install. We don't publish standalone binaries today — the CLI versions with the server it talks to. If you depend on a specific subcommand, pin a tagged release.

Updated

Was this page helpful?