API

Chat9 exposes its HTTP API at https://api.getchat9.live. The pages below are generated directly from the live OpenAPI spec, so they stay in sync with the running service. Three authentication models are in use; the rest of this page explains them, then the sidebar takes over.

Hosts

• API host: api.getchat9.live — every endpoint documented here.
• Widget loader: widget.getchat9.live/widget.js — a separate Vercel project, served as a static script. You don't call it from your code; the <script> tag does.

Authentication

Three surfaces, three credentials:

• Public widget endpoints (under the widget tag in the sidebar: POST /widget/session/init, POST /widget/chat, GET /widget/history, POST /widget/escalate, GET /widget/config) — unauthenticated in the HTTP-headers sense. Each request is identified by the bot's public_id (starts with ch_, same value as your widget's data-bot-id). Each endpoint has its own per-IP rate limit. Optional identified sessions attach an HMAC-SHA256 token signed by your backend.

• Server-to-server chat (POST /chat, POST /chat/{session_id}/escalate) — authenticated with your ck_... API key issued in Settings → API keys. Send it as an X-API-Key header. This is the credential for custom backend integrations that drive a conversation from your own server, not from the embedded widget.

• Dashboard / management endpoints (Documents, Gap Analyzer, Knowledge, and the read side of Chat — sessions, logs, history) — authenticated with a JWT bearer token. POST /auth/login with your e-mail and password returns an access_token; send that as Authorization: Bearer <access_token> on each request. A ck_... key does not authenticate these routes. The account-level endpoints themselves (sign-up, login, tenant settings, bot CRUD) are not part of the documented surface — they live behind the dashboard at getchat9.live.

Streaming responses

POST /widget/chat returns a text/event-stream (Server-Sent Events). The stream emits three event kinds while it works:

• {"type":"status","stage":"..."} — progress signal (e.g. "thinking"). Safe to ignore if you only want the answer text.
• {"type":"chunk","text":"..."} — partial reply text. Concatenate successive chunks to render the answer as it arrives.
• {"type":"done","text":"<full reply>","session_id":"...","chat_ended":false} — emitted exactly once at the end with the complete reply, the session_id, and a chat_ended flag. May also include ticket_number (turn opened a support ticket) and sources (URL-backed citations).

If something goes wrong server-side you may instead get one {"type":"error","code":...,"message":"..."} event before the stream closes.

The OpenAPI schema describes the server's accepted request shape; SSE event payloads are documented above (OpenAPI doesn't model SSE event bodies natively).

Models used by the chat pipeline

POST /widget/chat and POST /chat generate answers with gpt-5-mini and run lightweight guard / validation checks with gpt-4o-mini by default. See Pricing and limits for cost guidance.

Source of truth

These pages are regenerated on every docs build from api.getchat9.live/openapi.json. If a page here ever disagrees with the live API, the live spec wins — file an issue and we'll regenerate.

Need help?

Email support@getchat9.live if you hit something this section doesn't cover.