TTS now accepts sample-rate and bitrate-specific output formats

1 min read

Speechify TTS speech and streaming endpoints now accept output_format values like pcm_16000, ulaw_8000, and bitrate-tuned mp3 variants without changing existing callers.

Developer Relations · SpeechifyAI Labs

Speechify TTS now accepts an output_format body parameter on both POST /v1/audio/speech and POST /v1/audio/stream. Use it when you need a specific codec, sample rate, or bitrate rather than the older bare audio_format field or Accept header path.

Existing callers do not need to change anything. If output_format is absent, the old defaults still apply.

Why add output_format?

Bare codec names are fine until you need telephony audio or bandwidth control. pcm does not tell an IVR stack whether you want 8 kHz, 16 kHz, or 24 kHz. mp3 does not tell a mobile client whether it should trade quality for file size.

The new values use the codec_sampleRate_bitrate shape:

  • pcm_16000
  • pcm_24000
  • ulaw_8000
  • mp3_24000_64
  • mp3_24000_128
  • wav_48000

There are more values in the API reference, but those are the ones that explain the feature fastest.

How precedence works

output_format wins when it is present. On /v1/audio/speech, it takes precedence over audio_format. On /v1/audio/stream, it takes precedence over Accept.

That means you can keep using Accept for existing streaming code while new clients move format selection into the JSON body.

Invalid values return 400 and list the supported formats. The response also echoes output_format when you set it, which makes request logs and batch jobs easier to inspect.

Who should use it first?

Telephony integrations should look at ulaw_8000 and pcm_16000. Media pipelines should look at the mp3 bitrate variants. If your current audio_format is doing what you need, leave it alone.

This is additive API work, not a new audio model. The point is to expose the format matrix the backend already supports without asking callers to infer it from MIME types.