Conversations

One Inbox, distinct conversations

Chat, email tickets, calls and supported messaging channels use conversation records. That common structure lets the Inbox organize different channels together. A later call does not automatically become part of an earlier chat thread: linked customer and request history provide the connection.

Core fields

A conversation has id, siteId, channel, status, assignedAgentId and groupId (department), plus channel-specific metadata. visitorId can be null. Channel values include chat, ticket, call and supported messaging channels; do not hardcode a three-value enum in a client. Some actions and data are specific to one channel.

Status and completion

Common statuses include open, pending, solved, spam, unanswered and closed. The status API accepts open, pending, solved or spam and enforces allowed transitions. Closed calls may be reopened or marked solved; closed is not an irreversible retention-expiry state.

A call ending, a conversation being archived and a support request being completed are different events. Follow-ups can remain outstanding after the call ends. Use the appropriate call/request actions rather than changing status to control a live phone connection.

Messages, notes and transcripts

Message authors are identified by senderType: visitor, agent, ai or system. Private notes have their own API and are not internal_note messages in the message list. Call transcripts have their own processing and availability state; do not assume all call audio becomes a standard chat-message row.

Ownership and access

All reads and mutations must use an authorized workspace session or a documented product-specific API. Department/channel access is enforced separately. Claiming or transferring an item can fail if another agent owns it; handle conflict responses and reload current state.