CLI

Run without installing

npx -y @index365/cli --help

Run the package directly with npx -y @index365/cli. It requires Node.js 20.18 or newer.

Authenticate

npx -y @index365/cli login            # asks how you want to sign in, then saves a key (0600)
npx -y @index365/cli whoami           # which account/org this machine is signed in as
npx -y @index365/cli doctor           # diagnose auth, version, and config (--fix applies safe fixes)
npx -y @index365/cli --status         # auth, org, plan, and Page Checks at a glance

npx -y @index365/cli login asks how you want to sign in. Browser (the default) runs a loopback + PKCE flow: it opens the dashboard consent screen, and once you approve it mints a scoped key and saves it locally. The secret never travels through a URL, and nothing is pasted. API key lets you paste a key from the dashboard API Keys page (available on every plan, including Free). To skip the menu, run npx -y @index365/cli login --web for the browser flow directly.

For CI or headless machines, pass npx -y @index365/cli login --key <key> or set INDEX365_API_KEY to use a key with no prompt. The CLI never prints your secret.

Scan a site end to end

npx -y @index365/cli projects list --status active
npx -y @index365/cli projects create --domain yoursite.com --name "Yoursite"   # add a project (idempotent by domain)
npx -y @index365/cli scan https://yoursite.com                    # waits, then prints the Marketing Signal result
npx -y @index365/cli scan https://yoursite.com --no-wait          # queue it and print the runId for async work
npx -y @index365/cli results yoursite.com                         # that site's scan history and score trend
npx -y @index365/cli check "$RUN_ID"                              # is that scan done yet?
npx -y @index365/cli findings list --run "$RUN_ID" --severity critical --json
npx -y @index365/cli findings get --run "$RUN_ID" "$FINDING_ID"   # one finding, with its fix prompt block
npx -y @index365/cli report "$RUN_ID"                             # compact JSON context for your agent
npx -y @index365/cli report "$RUN_ID" --save report.json          # full JSON report
npx -y @index365/cli projects archive "$PROJECT_ID" --confirm yoursite.com   # reversible removal (echo its domain)
npx -y @index365/cli projects restore "$PROJECT_ID"               # reactivate the same project and history

scan resolves the project from the URL's domain automatically, because projects are domain-anchored. If the domain has no project yet, the command errors and prints the exact projects create command to run; it never creates one for you and never prompts in a non-interactive shell. Pass --project to override the resolution. The command waits by default and prints the score when the scan finishes; --no-wait queues the scan and prints the runId instead.

results lists your scans newest first (previously runs list); a domain narrows it to that site's history, the fastest way to prove a fix moved the score. check answers "is a scan done yet?" (previously runs get): with nothing it checks your most recent scan, and it accepts a run id, any unique id prefix, or a domain.

findings list filters by --severity, --category, and --stage. findings get includes a fix prompt block: a ready-to-paste prompt for your coding agent, the same text as the dashboard's copy-fix-prompt button. report has three forms: report "$RUN_ID" prints compact JSON context sized for an agent's first read, --save writes the full JSON report to a file, and report --project "$PROJECT_ID" returns the latest completed Marketing Signalreport for a project. Use an explicit run ID to read historical reports.

Archive removes a project from active lists and blocks new scans, but preserves its scan history and API keys so it can be restored. index365 projects delete is a hidden compatibility alias for archive and reports the result as archived. Use --status archived to find projects you can restore, or --status all to include every lifecycle state.

A project's domain covers its apex and every subdomain, so scan can score staging.yoursite.com or pr-42.preview.yoursite.com under the same project without creating a new one.

Marketing Signal scans

npx -y @index365/cli scan https://yoursite.com --product marketing-signal        # six-category Marketing Signal scan
npx -y @index365/cli report --project "$PROJECT_ID"                              # latest completed Marketing Signal report
npx -y @index365/cli findings list --run "$RUN_ID" --stage measure --json
npx -y @index365/cli integrations list --project "$PROJECT_ID"                   # connected-signal providers
npx -y @index365/cli integrations status --project "$PROJECT_ID"                 # provider connection health

Repository scans

scan repo checks what your code says about your marketing surface: which tags are wired, where they mount, and which ones are inert because their id comes from an environment variable. It reads the repository on your own machine.

npx -y @index365/cli scan repo --dry-run                        # print the artifact that WOULD upload, then stop
npx -y @index365/cli scan repo ./my-site --project "$PROJECT_ID"  # walk the repo and grade it
npx -y @index365/cli scan repo . --redact-ids --fail-under 70     # hash vendor ids; fail CI on a low category

Your source never leaves your machine. The CLI walks the repository locally and uploads citations (vendor, file, and line), not file contents. Environment files are never opened, so a tag's configuration variable is reported by name and its value is structurally unavailable rather than merely withheld. Run --dry-run to print the exact bytes that would be sent; it needs no account, uploads nothing, and spends nothing.

A repository scan grades what code can prove, so it reports a smaller audit rather than the same audit with holes. It can show tag coverage across every route at once, tags that are wired but inert, and duplicate containers. A single rendered page cannot demonstrate any of those. It cannot see response headers, DNS, TLS, redirects, or anything requiring a rendered page, so those checks are absent rather than guessed, and a repository run does not produce a headline Marketing Signal score. Run npx -y @index365/cli scan <url> against the deployed site to grade the published experience.

Re-uploading an unchanged tree replays the previous run instead of spending again, so the fix-and-rescan loop only costs you when the code actually changed.

CI example

In automation, pin a real version: npx -y @index365/cli@<version> ....

# Fail the pipeline when a deploy degrades Marketing Signal
npx -y @index365/cli@<version> scan "https://yoursite.com" --json > run.json
score=$(jq -r .score run.json)
test "$score" -ge 70 || { echo "Marketing Signal score $score below 70"; exit 1; }

scan waits for the result by default, so the JSON on stdout already carries the final score. Live scans evaluate the registered project URL and preserve evidence labels in the returned result.

Conventions

• --json on every command prints the raw API payload for scripts and agents.
• Stable exit codes: 0 ok, 1 error, 2 usage, 3 auth, 4 not found, 5 quota/conflict/rate.
• --status prints a one-glance card: auth and key source, organization, plan, and Page Checks remaining.
• npx -y @index365/cli mcp config prints local-host setup for Claude Code, Codex, and Cursor. See the MCP guide for hosted connections.
• -h prints help for any command, with examples; -V prints the CLI version.

Migrating from 0.x

CLI 1.0.0 renames the scan grammar: scan is the verb, and products are values of --product, never command prefixes. Every old spelling keeps working as a hidden compatibility alias for at least 90 days: it runs the new command and prints a one-line rename note. Aliases no longer appear in help.

Drive the CLI from your agent

The index365 agent skills wrap these commands so your coding agent can run a scan and apply fixes in one instruction. Run and authenticate the CLI first, then see Agent skills for the one-command install.