Skip to main content
POST /v1/audio/transcriptions turns a recording into text. It has the shape of OpenAI’s audio transcriptions, so an OpenAI SDK’s audio.transcriptions.create works by changing base_url alone.

It runs on a dedicated deployment

Speech-to-text models are offered as dedicated deployments: create a deployment of a model that transcribes, then send its full name as model:
A bare model name, or a deployment of a model that does not transcribe, returns MODEL_CAPABILITY_UNSUPPORTED. The other way round is refused too: a speech-to-text deployment does not answer /v1/chat/completions.

Sending audio

Other formats (mp3, ogg, webm) return MEDIA_UNSUPPORTED: convert them to WAV first. A recording of 16 kHz mono 16-bit PCM — what voice pipelines usually produce — is about 32 KB per second.

What comes back

With response_format: json:
usage.seconds is the recording’s length read from the WAV header, rounded up to whole seconds. With response_format: text the body is the transcript alone, as text/plain. With stream: true the answer is text/event-stream: one transcript.text.delta event per new piece of text, then a single transcript.text.done carrying the whole text and the usage, which ends the stream. There is no [DONE] line — unlike chat streaming.

Using it from a voice agent

Pipecat’s OpenAI speech-to-text service takes a base URL and a model, which is all it needs:
The API key needs the audio operation if you restrict its operations; a key with no operation restrictions can already call this endpoint.

Cost

A dedicated deployment is billed for the GPU time it holds, whether or not you send anything. Transcription calls are not billed on top of that: each one appears on the Usage and Requests pages with its audio length, at no charge.