> For the complete documentation index, see [llms.txt](https://docs.concurrence.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.concurrence.com/channels/voice/recordings.md).

# Call Recordings

Workspace-scoped caller, agent, and merged stereo recordings with time-limited download links and best-effort availability.

When call recording is enabled, the voice runtime can retain caller and agent audio as separate WAV files and create a merged stereo WAV during finalization. Platform-managed and `gpt_realtime` calls, phone and Playground, are recorded the same way. Playback uses those stored artifacts.

Recording finalization is best-effort. A call can complete successfully even when a recording is missing or incomplete. A successful request for download links does not prove that the files exist; the client must handle the result of fetching each link.

## Channels and Timing

| Channel    | Contents                               | Playback behavior                                   |
| ---------- | -------------------------------------- | --------------------------------------------------- |
| **Caller** | Inbound caller audio                   | Stored as a mono WAV                                |
| **Agent**  | Spoken agent audio                     | Stored as a mono WAV                                |
| **Stereo** | Caller on the left, agent on the right | Created during finalization and stored for playback |

Voice recordings store the mono channels as 8 kHz mu-law WAV and the merged stereo file as decoded PCM WAV. Each file carries its codec and sample rate in the WAV header. Clients should read that header rather than assuming that every WAV contains PCM audio.

The runtime aligns outbound audio with the inbound timeline during capture. This shared timing origin lets playback views align transcripts, agent speech, tool activity, and other call events without treating each channel as an independent recording.

## Playback and Review

The Platform API authenticates the requester, verifies workspace access, and returns time-limited links for the caller, agent, and stereo files in that workspace. It does not check file existence before issuing those links. A missing artifact fails when the link is fetched.

Treat download links as temporary access to sensitive audio: share them only with authorized recipients and request fresh links after expiry. The recording interface does not provide separate metadata, waveform, or stereo-transcoding endpoints. A playback client derives file metadata and waveforms from the downloaded audio.

## Availability and Retention

Recording availability depends on deployment configuration and successful finalization. Some calls lack the merged stereo artifact even when individual channels exist. Retention requirements should be configured and validated as part of the workspace's data-handling policy; stored retention settings are advisory and do not by themselves enforce deletion. See [Retention Policies](/operations-and-safety/compliance.md#retention-policies).

{% hint style="info" %}
For terminal intelligence and recording-based review, see [After the Call](/channels/voice/audio-pipeline.md#after-the-call). For timeline review that aligns speech with agent actions, tool calls, and system events, see [Call Playback Timeline](/intelligence-and-analytics/intelligence/call-intelligence.md#call-playback-timeline).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.concurrence.com/channels/voice/recordings.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.