Stand, from your terminal.

You need Node.js 22 or newer and npm on macOS, Linux, or WSL. On Windows, run these commands inside WSL; native Windows is not supported. A coding agent needs access to that terminal too.

Install @standchat/cli globally, then check the executable and version. You can run Stand commands from any folder. If the official package cannot be installed, check the error instead of substituting a similarly named package.

The unpinned install command follows npm’s latest tag. Run the same command to update, and record stand --version when asking for help. Package versions and npm tags do not choose your API environment.

For website setup, use the setup permission preset. Keep the login command running. It prints a verification URL and a separate user code; open the URL yourself, sign in or create an account, and review the requested access.

After the browser says “Stand CLI authorized”, return to the terminal and wait for credential storage to finish. Then check setup status. If it reports browser_onboarding_required, open the indicated dashboard with the same account, complete your profile and organization, and run the check again.

Inspect the ready and status fields, not just the command’s exit code. A ready result means account configuration can begin. It does not mean a widget is installed or a visitor has received an answer.

The default profile targets Stand production. Create a named profile before logging in to staging or a preview. A name such as preview1936 is only a label: it does not discover URLs or start a preview environment.

Save the verified API origin and issuer together, then use --profile on each command. A preview needs its own deployed endpoints. For a custom environment, setup status also accepts --app-url with its verified dashboard origin.

config list shows saved configuration. auth status shows the endpoints resolved for the current invocation. STAND_PROFILE selects a saved profile; STAND_API_URL and STAND_ISSUER override endpoints without rewriting it. Credentials are bound to the selected API and issuer, so changing the target may require a new login.

Use --help for a readable overview and commands --json for machine-readable discovery. Each named command describes its inputs and whether it needs mutation confirmation. schema takes an operation ID and shows its required scopes and request shape.

List existing Sites, Stand-ins, and knowledge bases before creating more. Keep their returned IDs in your working notes, reuse the intended resources, and check the account’s plan and usage. A display name is not a reliable resource identifier.

For an operation without a named shortcut, stand api accepts its published method and /v1/ path. It uses the same authentication and permissions and only supports operations in the bundled public API contract.

Start with the Site and Stand-in lists. If the website has no matching authorized Site, create one using its hostname, such as example.com, rather than a full URL. Read its returned snippet field for the installation code.

For a new Stand-in, save the example below as standin.json, replace SITE_ID, and write an approved briefing. Creation leaves the Stand-in disabled. Add and verify its knowledge before enabling it.

When updating an existing Stand-in, read it and inspect updateStandin first. The update body is a complete set of writable settings; omitted values can clear existing configuration. Keep the standinProfileId returned by the save, because it can change. Attachment writes likewise replace the full list.

Read knowledge list for effective capabilities, ingestion availability, remaining capacity, and graceReadOnly before a change. Check each base’s ownedByCurrentRep value: uploads, replacements, recrawls, cancellations, and deletions require that base’s owner, even if you own the organization. The Base plan can use approved instructions and supported public website crawling. Uploads require documentUploadAllowed, normally on Pro or Business; sitemap creation needs sitemapAllowed, and nightly refresh needs automaticRefreshAllowed.

Use a public crawl for approved website content. For local documents, upload the file directly when permitted. Approve sharing private content with Stand and using its facts in visitor answers; do not publish a private document just to make it crawlable.

Uploads accept nonempty PDF, DOCX, Markdown (.md or .markdown), and TXT files up to 10 MiB each. The separate 11 MiB CLI content budget and 12 MiB encoded API request limit do not increase that document limit.

A Site rename can use the name flag alone. Site instructions are a separate complete replacement: read the existing text, prepare all the intended content in a file, and review it before saving. Both changes require sites:write and the organization owner; reads also need sites:read.

Personal chat coverage is different from the Site’s enabled state. Use sites preferences get to inspect your selection and sites preferences update SITE_ID --enabled true to change just that Site while preserving the other selections. This does not make you available for incoming chats.

Image uploads use stand api with a local file. Read the target first and inspect the upload schema. The example changes an existing Stand-in avatar immediately; it does not need a later Stand-in settings save and keeps the same ID.

Avatars accept PNG, JPEG, GIF and WebP up to 5 MiB. Animated avatars have tighter dimensions, frame and size limits in the operation schema. Do not confuse these image limits with the 10 MiB knowledge-document limit.

Use an agent that can run terminal commands and edit the intended website project. For installation, it also needs a way to inspect the real website in a browser. A chat window without those tools can explain the steps but cannot complete the installation for you.

For first setup, ask “Add stand.chat”. The agent can discover the official instructions, install the CLI, inspect your project, and propose the configuration. You still complete browser signup and consent, approve the content and changes, and authorize publishing.

For ongoing work, name the account profile, target resources, approved sources, and intended outcome. Ask the agent to inspect first and show its proposed changes. CLI permissions and --yes do not expand the work you authorized.

Conversation reads need sessions:read, which is not included in the setup preset. Request it explicitly for the approved task; add other scopes only if that task needs them. Organization-wide history remains subject to account roles.

Use a bounded search to inspect results before exporting. The --site filter matches text anywhere in the stored page URL, not an exact hostname; check returned URLs when you need an exact-site sample. Date filters use timestamps with a timezone; closed-to is an exclusive upper bound. If you request all search pages, inspect complete and nextPage rather than assuming every matching conversation was returned.

Read a selected conversation with sessions get SESSION_ID; it returns at most 500 messages. Use an export for complete retained transcripts. Export writes validated JSON to a new private file and refuses to overwrite an existing destination. Keep it outside the website repository and share it only with approved people or tools.

Use sessions list and sessions get to inspect an active conversation you are allowed to handle. Polling with sessions get --watch does not make you available or subscribe you to background notifications. Organization-wide archived reads do not grant access to another rep’s live conversation.

Agree the exact reply before sending. A message to a Stand-in conversation can take over that conversation as you, so approve the handoff as well as the text. The named send command verifies your identity before writing and checks the returned message against that identity and the approved body.

Generate a UUID and save it as clientMessageId alongside body in message.json before sending. Keep that file for this one logical message. If the field is absent, the CLI generates an ID but does not write it back to your file, so a forced process exit could leave you without the key needed to reconcile the result.

JSON is automatic when stdout is not a terminal; --json makes the choice explicit. Read results from stdout and diagnostics or login progress from stderr. Use commands --json for machine discovery, not --help --json, which remains readable help text.

Pass JSON requests with --body-file FILE, or --body-file - for standard input. Without an interactive terminal, mutations need --yes. Add it only after the specific changes have been authorized; keep read-only discovery separate from writes.

For unattended work, use an authorized credential in private user storage or inject STAND_ACCESS_TOKEN through your secret manager together with the matching STAND_TOKEN_API_URL. Do not put tokens in command arguments, URLs, source files, logs, or agent prompts. STAND_CONFIG_HOME can select an absolute private configuration directory.

GET requests retry a bounded number of transient failures. Writes do not automatically retry. After a timeout, lost response, cancellation after dispatch, or server error, read the affected resource and reconcile its ID and content before deciding what to do next. The original change may already have succeeded.

Include the CLI version, command, selected profile, and sanitized error when asking for help. Check the installed command schema before trying a flag from a newer release. Keep credentials and private conversation content out of reports.