Feature referenceApps and integrations · 03 of 03

Apps and integrations

Stand CLI

Install and manage Stand from a terminal or coding agent. The CLI provides browser authorization, named commands, schema discovery, uploads and history export, with readable output for people and JSON for automation.

Availability
All plans
Configured in
A terminal or coding agent; signup, consent and initial profile setup in the Stand browser flow
Category
Apps and integrations
Reference status
Current

Before you begin

Plan availability: All plans, including Base, within the organization’s existing allowances. The official CLI package must be available from npm.

Prerequisite: Node.js 22 or later on macOS, Linux or WSL; network and browser access; an active organization after browser onboarding. Installation also requires permission to edit and publish the website.

Key boundary: Account deletion, subscription/payment management and team-member changes are excluded. Site JavaScript experimentation and Stand-admin behavior access require prior owner opt-in in the browser. MCP, WordPress and representative WebSockets are outside this surface.

01

Start with “Add stand.chat”

Copy “Add stand.chat” from the homepage and paste it into a coding agent in your website project. The agent discovers the setup instructions through /llms.txt; you do not need to provide a guide URL or install Stand tools in advance. The homepage’s How it works link explains the flow for people.

The agent follows those instructions to configure and install the chat, while the account holder completes signup, consent and initial profile onboarding in the browser.

02

Browser authorization and account readiness

Run stand auth login --setup for installation. The CLI provides a trusted verification URL and user code. The account holder completes signup or sign-in, terms and permission consent. Passwords and browser cookies are not handed to the agent.

Social signup started by the CLI asks for terms acceptance in the browser authorization flow when no prior acceptance is recorded. Homepage social signup keeps terms acceptance in its existing registration dialog.

After successful authorization, the browser shows “Stand CLI authorized” and can be closed. Return to the terminal and check account readiness; authorization alone does not finish profile onboarding.

stand setup status checks readiness and provides the browser onboarding URL when needed. The human completes the existing profile form with the same account. The CLI cannot create the initial profile or organization; it can edit an existing profile after onboarding with explicit profile-write permission.

Every operation requires its granted scope plus normal active membership, ownership, role and plan permissions. Renaming the organization through a profile update also requires organization-write permission. Disabled accounts or organizations cannot continue with a previously issued token.

Setup login requests eight business scopes: profile and organization reads, plus Sites, Stand-ins and knowledge read/write. Other management tasks use stand auth login --scopes with the permissions they need; a setup request does not authorize unrelated changes.

03

Commands for people and automation

Use stand --help and stand commands to explore the 73 named commands. stand schema OPERATION_ID describes a request; the generic stand api command reaches all 109 published management operations under the same permissions.

Ordinary terminal examples do not need --json. Add it when an agent or script needs structured output; piped output is also JSON. During JSON login, the verification URL and code are emitted on stderr as a device-authorization event.

Writes request confirmation. Use --yes only for an already approved change; it does not grant permission. --no-input prevents interactive prompts and cannot complete browser login. Inspect the command’s confirmation metadata before automating it.

Use named knowledge commands for approved uploads, website or sitemap ingestion, indexing status, document inspection and search. Image uploads, Site prompts, conversations and filtered history exports use the same operation schemas.

Exit codes distinguish usage errors (2), missing resources (3), authorization failures (4), network or response-validation failures (5), cancellation (130), and other failures (1). A malformed response can fail validation even when the HTTP status alone would map differently.

04

From configuration to an installed chat

  • The agent checks existing resources and the plan before creating a dedicated Site and Stand-in. A new Stand-in begins disabled.
  • Knowledge must finish indexing before the agent reports it as available. Base can use approved instructions and website crawling within its normal allowance. When the account allows document uploads and ingestion, an approved local document can be uploaded without publishing it on the website; private material requires specific approval and must suit the chat audience.
  • Knowledge attachment writes replace the complete list. Read and preserve intended existing attachments before changing it.
  • The Site, Stand-in and owner’s Stand-in coverage must be enabled. The owner-wide switch also affects other enabled Stand-ins owned by that member.
  • The agent installs the Site’s returned snippet once using the website framework’s normal script lifecycle. The snippet contains a public Site identifier, not management credentials.
  • A real visitor message and answer on the intended hostname verify the installation. An installed flag, greeting or eligible routing match alone is insufficient.
05

Credentials, interruption and retries

Credentials stay in the CLI credential store outside the website and repository. On a host without an available secure vault, private local-file storage must be selected explicitly. Short-lived access tokens refresh within existing session limits; expired or revoked authorization requires another browser authorization.

Retain successful resource IDs, inspect existing resources on resumption and reconcile uncertain writes. The CLI does not blindly retry mutations. Names are not unique resource identities, and this API does not promise conditional revision checks. Preserve intended existing members when replacing collections.

CLI reads do not make a person Available or refresh human presence. Explicit personal Site-preference changes are supported, but representative WebSockets remain unavailable. The installation recipe leaves human availability unchanged.

06

Availability and boundaries

  • Install the official package from npm’s latest tag with npm install --global @standchat/cli, and record the installed version. If unavailable, stop and report the missing distribution; do not substitute another package or pasted access tokens.
  • The supported hosts are macOS, Linux and WSL with Node.js 22 or later. Native Windows is not supported.
  • A coding agent needs authorized project access, a shell, network access and a real browser. Deployment requires the website’s normal publishing access.
  • Private content requires specific approval before sharing. Public website content and Stand-in instructions should contain only information appropriate for visitors.
  • MCP connections and WordPress plugins are outside this API and CLI surface. No plugin directory installation is required.
  • An agent without deployment access or a verified visitor answer reports the remaining work instead of reporting a completed installation.