Conversations
A conversation is the canonical "result of a call" in Delphi. Every WebRTC session, every inbound SIP call, every test call produces a conversation entry — with its transcript, tool invocations, timing, and (when enabled) a recording.
This is a concept page. In v0.9.11 there is no programmatic read REST endpoint for conversations — they're read via TelWeb's per-app conversation history, or surfaced in realtime over the WebSocket channel for active WebRTC sessions. This page is here so you can plan integrations against a stable mental model regardless.
What's in a conversation
| Aspect | What it contains |
|---|---|
| Identity | Conversation ID, tenant ID, endpoint ID, flow ID, started/ended timestamps. |
| Participants | Caller side (a SIP URI, or a tenant user in WebRTC, or a test session). |
| Timeline | Ordered events — user utterances, AI utterances, tool calls, node transitions. |
| Transcript | Per-turn text — what the user said and what the AI replied. Diarisation depends on provider. |
| Tool invocations | Each tool call's inputs, outputs, errors, and duration. |
| Recording | Audio file in the platform's recording bucket, surfaced as a signed URL on read. |
| Telemetry IDs | A trace ID that ties the conversation into SigNoz monitoring. |
Recordings are only produced when RECORDING_ENABLED=true at the platform level — see Voice operations.
Lifecycle
- A call starts (WebRTC, SIP, or test). A conversation row is created and updated as the call progresses.
- The call ends. The Voice service writes the final timeline and uploads any recording artefacts.
- Post-processing runs on the Ops service — recording transmuxing, diarisation refinement (where supported), and webhook dispatch.
- The conversation is now stable — most fields don't change after this.
You will typically read conversations after step 3. Reading too early can return a partial timeline.
Where the API surfaces it
In v0.9.11 the customer-facing read surface for conversations is in TelWeb (per-app conversation history). There is no programmatic conversation-read REST endpoint yet.
If you need to know that a conversation finished from outside Delphi, the current pattern is:
- For WebRTC sessions, your client is already attached over the WebSocket channel and sees the conversation's end events in real time. The client SDK surfaces them as typed callbacks.
- For server-side post-processing, no outbound platform-to-tenant webhook exists . (Note:
/api/v1/webhooks/*is the inbound async-LLM endpoint, not an outbound event stream — see Webhooks.)
If you need a programmatic read API now, surface it as a feature request in Getting help so it can be prioritised.
Privacy and retention
- Retention is platform-configured. The user-facing data — transcripts, recordings — is subject to your install's data policy.
- A delete in TelWeb does not necessarily delete the recording in object storage immediately. Operators should review the bucket lifecycle policy alongside any data-deletion request.
- If you receive a tenant-side deletion request, propagate it to your platform admin (or your operator) so the underlying objects can be removed in tandem.
See also
- WebSocket channel — realtime conversation events during a WebRTC session.
- Webhooks — the inbound async-LLM callback endpoint (often confused with outbound events).
- Conversations (user guide) — what tenant users see in TelWeb.
- Voice operations — where recordings come from.