Overview

The Public API is the only Assistive API you write code against. These six endpoints are its complete surface: three for conversations, three for the help center.

Reach for this API when you're building the interface yourself — a chat screen in a native app, a support panel in your product, a help center rendered by your own site — and calling from your own backend.

If you just want chat on your website, you don't need any of this: install the widget instead and write no API code at all.

Two credentials

The split between the two credentials is the design of this API, not an accident of it. Authentication has the full reasoning.

• A publishable key (pk_) identifies your organization. It can start a conversation and read the help center — nothing else. It cannot read or write any conversation that already exists. Keep it on your server.
• A visitor token (vt_) identifies exactly one conversation. It's minted when you start that conversation, returned once, and is the credential for reading and posting on it. This is the only credential that may reach an end user's device.

Conventions used here

Every entry assumes these, rather than repeating them:

• Base URL. Paths are written from the root; prefix them with your base URL. Examples write it as {BASE_URL}.
• Envelope. Every response — success or failure — is wrapped in the same {success, request_id, data, error, meta} envelope. Entries show the full envelope in examples but describe only the data payload in prose. See the response envelope.
• Errors. Each entry lists only the errors it can actually return. What to do about each one is in Errors.
• Examples. Every example uses the same fictional organization (Acme), the same fake key (pk_example…), and the same fake IDs, so you can follow one conversation across several endpoints.

What this API does not do

• No attachments. There is no upload endpoint and no attachment_ids field. File attachments exist only in the widget.
• No polling cursor. List messages returns the whole customer-visible thread every time; diff on message id client-side.
• No webhooks and no streaming. Neither exists today. Clients poll.
• No access to tickets, staff, teams, or reports. Those are dashboard-only and answer to a staff session, not to any key you can hold.