Query parameters
Response
The200 response is { "items": [...], "total": 1 }. total counts the visible scopes matching the channel filter, not just this page.
One email thread can have multiple scopes for different participant cohorts. Key state by
scope_id, not just conversation_id. State and visibility can change between requests; neither a stored status nor an activation ID authorizes a future read or send.
Status values
Administrators can see an activation reference on an unavailable scope; that does not make its history readable. Recheck the endpoint rather than relying on a cached state.
An activation is bound to the sender whose qualifying message triggered it. Continued Companion access depends on that sender’s active exact inbound and outbound allows and verified group membership. Another eligible participant does not automatically take over an unavailable activation. Readiness or a new activation must not rebind an older queued reply.
Reply reasons include
companion_reply_unavailable, text_sending_unavailable, recipient_consent_required, and recipient_opted_out. Receiving permission and SMS consent are separate. A readable group can have reply_ready: false; activating it does not opt anyone in. See SMS opt-ins.
Examples
The SDK examples use an authenticatedclient.
state is a CLI alias for conversations. CLI JSON uses camelCase, including scopeId, activationId, and replyReady. Increase offset by the number of returned items until you have read the visible list. This list is not a stable activation-history snapshot.
For polling agents, load any uninitialized current activation with the complete initialization helper, persist its checkpoint, then read new messages through the ordinary channel APIs.
Errors
See configuration, activation history, and revocation.

