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

Request mapping

For POST requests, the most important change is that Gradium takes the voice in the JSON body instead of the URL path: 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.