Conversations are always created by a visitor through the chat widget — never via the API. The API is read-and-update only on the conversation itself; the one thing it can create is an agent reply on an existing conversation.
What you can do
Read
List conversations, fetch a single conversation, paginate its messages, read notes, list assigned tags.
Update metadata
PATCH /conversations/{id} to change status, priority, contact fields, assignee, or title.Reply as an agent
POST /conversations/{id}/messages posts a human-agent reply. Triggers human-takeover side effects.Organize
Pin notes, assign tags from your org-level palette via replace-set semantics.
What lives under a conversation
| Sub-resource | Endpoint | Notes |
|---|---|---|
| Messages | /conversations/{id}/messages | Full thread, including system markers. POST posts an agent reply. |
| Notes | /conversations/{id}/notes | Internal annotations. Not visible to the visitor. |
| Tags | /conversations/{id}/tags | Replace-set on PUT. Tags themselves are managed under /conversation-tags. |
The shape of a conversation
Cost data — tokens, credits, model used, billing rates — is intentionally never exposed via the API. Inspect usage in the dashboard.
Where next
Agent replies
Posting messages from an API caller. What it triggers, what it doesn’t.
Lifecycle
Status transitions, system markers, and which events fire when.
Object reference
Every field on the conversation object.
Conversation tags
Reusable org-level labels with replace-set assignment.

