Chatbot CLI: Provision a Support Chatbot From Your Terminal

Standing up a support chatbot usually means a signup form, a dashboard tour, a crawl with a progress bar, and a copy-paste snippet at the end. That takes about fifteen minutes, most of it waiting.

From a terminal, the same result is one command, and the first working bot exists before anyone signs up.

Who is the SiteGPT CLI for?

The CLI is for anyone who provisions, trains, or configures chatbots often enough that doing it by hand gets old. It is published on npm as @sitegpt/cli, the official SiteGPT command-line interface, and it also runs the checks you want before shipping.

It fits these four situations:

Use the dashboard instead for browsing conversations, reading analytics visually, or tuning appearance by eye. The CLI can read conversations and leads, but a terminal is a poor place to skim fifty transcripts.

How do you install and authenticate the CLI?

Install the package globally from npm. It needs Node 18 or newer.

npm install -g @sitegpt/cli
sitegpt --version

0.5.2

There are two ways to authenticate, depending on whether you already have an account.

No account yet. Skip login entirely. The onboarding flow in the next section returns its own token, scoped to the temporary workspace it creates.

Account you already own. Run sitegpt login, or set SITEGPT_API_TOKEN in the environment. Keep the token out of the command line itself, where it lands in shell history and CI logs. Scoped tokens are created with sitegpt tokens create, which takes repeatable --scope and --chatbot flags plus --expires-in-days, so an automation token can be restricted to one bot and expire on its own.

A command run with no credentials fails with an explicit error code instead of a stack trace:

sitegpt whoami --json

{
  "ok": false,
  "error": {
    "code": "PROFILE_NOT_CONFIGURED",
    "message": "Run `sitegpt login --token <token>` or set SITEGPT_API_TOKEN.",
    "hint": "No account yet? `sitegpt onboarding start <website-url>` is public and returns a temporary token, build a preview chatbot with no login."
  }
}

Named profiles (sitegpt profiles, then -p <name> on any command) keep a client account and your own account apart. Agencies should set one up per client before running anything.

How do you create a chatbot from the command line?

Run sitegpt onboarding start with a URL. It needs no signup:

sitegpt onboarding start https://sitegpt.ai --json

Real output, trimmed to the fields you actually use downstream, with the token truncated:

{
  "ok": true,
  "data": {
    "workspace": {
      "id": "7bb665c3-cd09-4404-85e1-47f948b3b778",
      "chatbotId": "b454b036-6a68-4088-81eb-817ed2adba64",
      "status": "CREATED",
      "createdVia": "AGENT",
      "expiresAt": "2026-08-26T08:12:59.144Z",
      "chatbot": {
        "title": "sitegpt.ai AI",
        "description": "AI customer support chatbot prepared from https://sitegpt.ai/"
      }
    },
    "apiToken": "sgpt_ee3a87f7f091_...",
    "mcpUrl": "https://sitegpt.ai/mcp",
    "onboardingUrl": "https://sitegpt.ai/onboarding/preview/7bb665c3-cd09-4404-85e1-47f948b3b778",
    "expiresAt": "2026-08-26T08:12:59.144Z"
  }
}

Four things came back that a script needs: a workspace id, a chatbot id, a token scoped to that workspace, and a URL a human can open to see the bot and claim it.

The preview is a working chatbot with small limits. Running sitegpt limits against that workspace on 2026-08-19 showed a 200 page and 50 message allowance, and the workspace expires seven days after creation. It lets someone see a working bot on their own content before deciding anything.

Three commands manage the rest of that lifecycle: sitegpt onboarding status <workspace-id> prints a setup checklist, sitegpt onboarding claim <workspace-id> moves it into a real account, and sitegpt onboarding delete <workspace-id> --yes throws it away and revokes the token.

How do you add knowledge and wait for training?

Use sitegpt knowledge with a source type, and add --wait so the command blocks until training settles. It is the biggest command group, because content is the product: website, sitemap, links, youtube, text, files, documents, sources for connections like GitHub and Confluence, and custom-responses for answers that must be exactly right.

A crawl, capped and blocking until it settles:

export SITEGPT_API_TOKEN=sgpt_...
sitegpt knowledge website add https://sitegpt.ai \
  --chatbot "$CHATBOT_ID" --depth 1 --max-links 20 --wait --timeout 420 --json

{
  "ok": true,
  "data": {
    "ingestJobRunId": "fc6145ca-e067-4b43-a061-8c100eb942fc",
    "source": "WEBSITE",
    "requested": { "url": "https://sitegpt.ai", "maxDepth": 1, "maxLinks": 20 },
    "training": { "settled": true, "pending": 0, "trained": 20, "failed": 0, "total": 20 }
  }
}

The training block is why --wait matters. Without it, the command returns as soon as the ingest job is queued, and the next line of your script reads a chatbot with nothing in it yet. With it, the process blocks until settled is true, and trained, failed, and total tell you whether to ship or investigate.

--wait is available on the add commands, and sitegpt knowledge wait --chatbot <id> does the same thing standalone. Both accept --timeout <seconds>, defaulting to 600.

Check these crawl flags before you point the CLI at a large site:

Set --sync from the start. Content that is not refreshed is the most common reason a bot that tested well starts hedging three months later, as the guide to why chatbots hallucinate explains.

How do you get the embed snippet?

Run sitegpt installation snippet with the chatbot id:

sitegpt installation snippet --chatbot "$CHATBOT_ID"

Chat URL: https://widget.sitegpt.ai/c/b454b036-6a68-4088-81eb-817ed2adba64
Widget script URL: https://widget.sitegpt.ai/widget/b454b036-6a68-4088-81eb-817ed2adba64.js

<script type="text/javascript">window.$sitegpt=[];(function(){d=document;s=d.createElement("script");s.src="https://widget.sitegpt.ai/widget/b454b036-6a68-4088-81eb-817ed2adba64.js";s.async=1;d.getElementsByTagName("head")[0].appendChild(s);})();</script>

Add --json and the same three values come back as chatUrl, widgetScriptUrl, and embedCode. Use that form when a template or a deploy step writes the snippet into a layout file.

Before you paste it anywhere, ask the bot something from the terminal:

sitegpt messages send "What content sources can SiteGPT train on?" --chatbot "$CHATBOT_ID"

Started conversation dbc82b42-ee5d-40ed-b118-950dc60ea514 and sent message e2450d68-2556-4ae7-9ae5-77ef60c0cc2b.
SiteGPT can train on a wide range of content sources including website URLs, sitemaps, YouTube videos/playlists/channels, raw text, and file uploads such as CSV, TXT, PDF, DOCX, PPTX, and Markdown files. You can also connect sources like Notion, Google Drive, Dropbox, OneDrive, Box, and GitHub to import training data.

Treat this as the acceptance test. If the answer hedges, fix the knowledge before touching prompt wording. Add the missing source, or pin the answer with sitegpt knowledge custom-responses for facts that must never be paraphrased, such as pricing and contact details.

How do you script the CLI in CI?

Add --json, rely on non-zero exit codes, and run with set -e. Every command accepts the global flags, and three of them matter for automation:

Failures exit non-zero. A missing token, an unauthenticated read, and an unknown command all exited 1 when tested, and the JSON envelope carries the reason in error.code instead of prose you would have to grep. Together they make the sequence safe to put in a pipeline:

#!/usr/bin/env bash
set -euo pipefail

CHATBOT_ID=$(sitegpt chatbots create "$CLIENT" --json | jq -r .data.chatbot.id)

sitegpt knowledge sitemap add "$SITE/sitemap.xml" \
  --chatbot "$CHATBOT_ID" --sync weekly --wait --json > /dev/null

sitegpt installation snippet --chatbot "$CHATBOT_ID" --json | jq -r .data.embedCode

With set -e, any failed step stops the job instead of shipping a snippet for an untrained bot. Shell completion comes from sitegpt completion bash or sitegpt completion zsh, sourced from your shell rc.

When the pipeline belongs to a larger integration, with scoped tokens to issue, webhooks to verify, and a backend calling the REST API directly, the SiteGPT API integration guide covers those parts.

Can a coding agent run the CLI?

Yes. Two features make the CLI easy for an agent to operate on its own.

sitegpt agent-guide prints the workflow and command map an agent should follow, including the instruction to run sitegpt <group> --help for exact flags rather than guessing a command name. SiteGPT also publishes a skill file at sitegpt.ai/agents/sitegpt-cli-skill.md and an auth discovery file at sitegpt.ai/auth.md, so an assistant can learn the whole surface without a human pasting documentation into a chat.

Onboarding also needs no login. Because onboarding start is public, an agent can go from a URL to a working, branded, tested chatbot and then hand a human the claim link. Nothing in that loop requires credentials the agent should not have.

SiteGPT publishes a setup guide for each client people drive it from:

• Claude Code in the terminal next to the repo
• Cursor in the editor
• Codex in CI pipelines
• OpenClaw for always-on agents that own support ops
• Hermes for agents that hold the role across sessions

The wider picture of what an assistant can operate end to end lives on the agents page. For how this fits the broader move to agents in customer service, see the AI agents hub.

Should you use the local or remote MCP server?

Use the remote server for a desktop assistant with a person signing in, and the local one inside CI or a container. Both let an AI assistant operate SiteGPT, but they authenticate differently.

The remote server at sitegpt.ai/mcp-server is hosted, authenticates over browser-based OAuth, and needs no install. sitegpt mcp runs the same server locally over stdio for clients that spawn a process. Claude is the confirmed MCP client.

The fastest Claude setup is the two-click install from Claude's connector directory, and the step-by-step guide covers the rest. For what changes about day-to-day work once an assistant can act, see MCP for customer service.

Once the bot is live, these ten analytics questions are a good first set of prompts to run against it.

Frequently asked questions

Do I need a SiteGPT account to use the CLI? You do not need one to start. sitegpt onboarding start <website-url> is public and needs no login. It returns a temporary workspace, a trained preview chatbot, a scoped API token, and a link to preview and claim it. The workspace expires after seven days and carries a small allowance, 200 pages and 50 messages when tested on 2026-08-19. You only create an account when you decide to keep the bot.

Which plan do I need for CLI access to an existing account? Driving an account you already own means authenticating with an API token, and the pricing page lists API Access on Growth, Scale, and Enterprise, not on Starter. Growth is $79 per month billed yearly, or $129 billed monthly. The anonymous onboarding flow is separate and needs no plan at all.

How do I wait for training to finish before the next step? Pass --wait to a knowledge add command, or run sitegpt knowledge wait --chatbot <id> on its own. Both poll until training settles and accept --timeout <seconds>, which defaults to 600. Without it, a script that reads the bot immediately will see zero trained documents.

Is the SiteGPT CLI free? The CLI itself is free and published on npm as @sitegpt/cli, and the anonymous onboarding preview is free to try. Running a production chatbot uses your SiteGPT plan. Every plan starts with a 7-day free trial, and the trial requires a credit card.

What is the difference between sitegpt mcp and the remote MCP server? Both expose SiteGPT to an AI assistant. sitegpt mcp runs the server locally over stdio, for clients that launch a process and for machines that already hold a token. The remote server at https://sitegpt.ai/mcp is hosted, connects over browser-based OAuth, and needs nothing installed.

Can an AI agent run the whole setup? Yes. The CLI ships sitegpt agent-guide, which prints the command map and workflow for an agent. SiteGPT also publishes a skill file and an auth discovery file. Because onboarding needs no login, an agent can create, train, brand, and test a chatbot, then hand back a claim link for a human.

How does the CLI behave in a script when something fails? Add --json and every command returns an envelope with an ok field. Failures set ok to false, carry a machine-readable error code such as PROFILE_NOT_CONFIGURED, and exit non-zero. That is enough to branch on in a shell script or a CI job.

Can it manage many chatbots at once? That is what it is for. Named profiles, scoped tokens, --json output, and non-zero exits on failure are all there so one script can provision and update dozens of bots.

Sources

• @sitegpt/cli on npm for the package name, version 0.5.2, and the Node 18 requirement
• SiteGPT CLI onboarding docs for the public onboarding flow
• SiteGPT MCP server docs for the local sitegpt mcp server
• SiteGPT MCP server page for the remote server and OAuth connection
• SiteGPT pricing for API Access by plan and the 7-day trial