Skip to main content
Clients send the same OpenAI Audio requests they would send to OpenAI. Auth and the consumer slug are the same as chat.
Speech returns raw audio bytes with the upstream Content-Type (for example audio/mpeg). TrustGate does not wrap the body in JSON. Transcriptions are multipart, same host and key:
On a Private data plane, add X-AG-Gateway-Slug as in the chat snippets. GET is rejected with 400. /v1/audio/translations and extra path tails are 404. OpenAI SDKs use the same consumer base URL: client.audio.speech.create() and client.audio.transcriptions.create().

​
Providers

Mistral speech uses voice_id upstream. If the client sends OpenAI voice, TrustGate copies it to voice_id. Mistral’s JSON {audio_data} (base64) is unwrapped to raw bytes so the gateway response stays OpenAI-shaped. xAI voice is a different wire (/v1/tts, /v1/stt). Anthropic, Gemini / Vertex, Bedrock, Cohere, DeepSeek, Cerebras, and other chat-only providers do not expose these routes. They are left out of the candidate pool. Chat input_audio parts are a different surface. The JSON model field is allowlisted as usual. For multipart transcriptions, TrustGate reads the form model field for allowlists, Azure deployment names, and @provider/model pins. It does not rewrite the multipart body.

​
Routing

  1. The consumer’s registries are filtered to those that advertise the matching capability (audio_speech or audio_transcription).
  2. Model resolution and load balancing run on that pool.
  3. Pinning a registry that cannot serve that audio path is a 400, not a failover — including @provider/model in a multipart model field.
  4. An empty capable pool is a 503.
Attach at least one audio-capable registry to the consumer. A mixed chat + audio pool is fine: chat still uses every chat-capable member; speech and transcriptions skip the rest.