Skip to main content
If your app already sends text to a provider and writes the returned audio to a file or stream, the migration is intentionally small: change the endpoint to Gradium, send your Gradium API key as x-api-key, and use a Gradium voice_id. The playback path can usually stay the same.

​
Endpoint swap

FlowExisting integrationGradium
One-shot TTSPOST https://api.elevenlabs.io/v1/text-to-speech/{voice_id}POST https://api.gradium.ai/api/post/speech/tts
Streaming TTSwss://api.elevenlabs.io/v1/text-to-speech/{voice_id}/stream-inputwss://api.gradium.ai/api/speech/tts

​
Request mapping

For POST requests, the most important change is that Gradium takes the voice in the JSON body instead of the URL path:
Existing conceptGradium field
{voice_id} path parametervoice_id
texttext
model_idmodel_name
Output format query/body settingsoutput_format
Provider API-key headerx-api-key header
Use the Gradium POST example as the replacement request. It returns raw audio bytes when only_audio is true, so existing “save the response body as audio” code can stay the same.

​
WebSocket mapping

For streaming TTS, the Gradium lifecycle is:
  1. Connect to wss://api.gradium.ai/api/speech/tts.
  2. Send a setup message with voice_id, model_name, and output_format.
  3. Send one or more text messages.
  4. Send end_of_stream.
  5. Read audio messages until Gradium sends end_of_stream.
Use the Gradium WebSocket example as the minimal replacement. Your receive loop should continue buffering audio chunks in the same place it buffered provider audio.

​
Checklist

  • Replace the provider URL with the Gradium endpoint.
  • Change auth to x-api-key.
  • Move the voice id from the URL path into voice_id.
  • Use a Gradium voice id from the voice library.
  • Keep your existing audio write/playback path.

Gradium TTS REST guide

Full POST schema, response modes, and supported output formats.