Skip to main content
The current live conversation read returns a count from the workspace’s shared cache. It does not identify sessions, stream transcripts, calculate sentiment, or produce live recommendations.

​
Read the available signal

Use Get live conversation count with a permitted workspace API key. The current implementation ignores agent_id and agent_ids; the result remains workspace-wide even when those parameters are supplied.

​
Design a useful live display

1

Label the scope

Display the selected workspace and identify the value as a workspace count. Do not present it as an agent-specific metric or a list of active calls.
2

Expose freshness and failures

Record when your application last completed a successful read. This is a fetch time, not proof of when the underlying counter changed. Use a bounded refresh policy and display stale or unavailable state after failed reads.
3

Verify the producer before alerting

In a deployment with a supported runtime, confirm that authorized test sessions change the counter as expected and that ended sessions are reconciled. Establish operational thresholds only after the counter’s behavior and freshness are understood.
The saved monitoring_enabled and monitoring_events fields do not establish a subscribable live event stream. Future transcript or insight streaming needs a released event schema, conversation-level authorization, delivery behavior, and retention policy. Review real-time monitoring and WebSocket preparation.

​
Frequently asked questions

Not without additional evidence. A missing cache key also returns zero, and the read does not report producer freshness.
No. Saved preferences are separate from a working producer, transport, authorization path, and interface.