> ## Documentation Index
> Fetch the complete documentation index at: https://docs.brightalk.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Recordings

> Understand the recording resource, its nullable fields, and the signed download URL.

A recording pairs one call's audio metadata with a short-lived signed download URL. `GET /recordings` and `GET /recordings/{recording_id}` cover every recorded call the organization has ever made — including calls started from the dashboard, a non-API Automation, or a batch — not only calls created through the Public API.

## Resource model

| Category | Fields                                                          |
| -------- | --------------------------------------------------------------- |
| Identity | `id`, `call_id` (nullable), `contact_id` (nullable)             |
| Timing   | `recorded_at`                                                   |
| Audio    | `duration_seconds` (nullable), `media_type`                     |
| Download | `download_url` (optional), `download_url_expires_at` (optional) |

`id` is derived from the underlying call row and is stable: fetching the same recording more than once always returns the same `id`. Treat every ID on this resource as opaque.

## Why `call_id` can be null

`call_id` is present only when the call was created through the Public API. In that case it is the same call `id` documented in [Calls](/en/concepts/calls), so you can retrieve that call's own summary and transcript. It is `null` for every recording whose call the Public API never created — dashboard dialing, a non-API Automation, or a batch that predates this resource. A `null` `call_id` is normal, not an error; on an established organization, most recordings do not have one.

`contact_id` is `null` under the same principle whenever a recording has no linked contact — an inbound call from an unrecognized number, a manual dial, or a contact deleted after the call. A small number of recordings also have a `null` `duration_seconds`. Parse all three fields as nullable; do not assume they are always present.

## No status field

A recording has no `status` or `reason` field. Every row `GET /recordings` returns has retrievable metadata by construction — whether its audio bytes are fetchable right now is answered only by the download step itself, not by a flag on the list or get response.

## The signed download URL

`download_url` is minted fresh on the request that returns it; it is never stored server-side and never the same value twice. It defaults to a 900-second lifetime and accepts an `expires_in` override between 60 and 3600 seconds. Treat the value as opaque — fetch it directly with a normal HTTP client instead of parsing, reconstructing, or caching its shape.

See [Download call recordings](/en/guides/download-call-recordings) for how to sync recordings completely, when to request the URL, and what happens to one already issued after you revoke access.