Skip to main content
Recording retrieval is API-only today — the terminal has no built-in player yet. The endpoints below are live and covered by service tests. Browser playback and seeking work through the gateway: a Range request returns a 206 Partial Content with its Content-Range and Accept-Ranges headers intact. See the capability truth table.
Alongside the diarized transcript, each meeting’s audio recording is uploaded to object storage — on a self-host, your own MinIO bucket, so it never leaves your environment. The recording is the meeting audio, stored separately from the transcript (speaker separation lives in the transcript as text — there is no per-speaker audio). Don’t have a key yet? Hosted: sign in at vexa.ai/signin with a Google account and copy your key from your account page — free credit, no card required. Self-hosted: make all prints a key when the stack comes up. To record a meeting without transcribing it and take the audio away for your own speech-to-text, see Capture now, transcribe later.

​
List recordings

Get the detail for one:

​
Get the playable audio

Resolve the master metadata (finalize-on-read), which points at the raw byte stream:
The response carries a raw_url of the form GET /recordings/{recording_id}/media/{media_file_id}/raw — the actual audio bytes the player loads:

​
Range requests (playback and seek)

The /raw endpoint honours HTTP Range — a partial request returns 206 Partial Content carrying Content-Range and Accept-Ranges: bytes, preserved through the gateway front door. This is what lets a browser <audio>/<video> element stream and seek the recording instead of aborting the fetch:

​
Where it’s stored

Recordings live in the bucket configured by MINIO_* (Configuration). On a self-host that’s infrastructure you control; a no-egress deployment keeps recordings entirely in-VPC.
A recording is the raw meeting audio. For the text of who-said-what with timestamps, use the transcript — see the Meetings API.