Speech endpoints (TTS and STT) on relay sites: what exists and what to test

Why speech is the capability you find out about last

You will always test text capabilities, because they are the main use. Speech, by contrast, tends to be added late in a project — by which point you have been running on a particular site for weeks and only then discover it is unsupported, or supported badly.

So: if your product roadmap includes speech, put it into the first round of supplier evaluation.

Three interface shapes

One: STT, speech to text

The standard OpenAI shape:

POST /v1/audio/transcriptions
Content-Type: multipart/form-data
file=@audio.mp3&model=whisper-1

Key points:

• It is multipart/form-data, not JSON. This alone defeats many gateways that only know how to forward JSON.
• Audio files usually have a size ceiling, 25MB officially, and a relay site may be lower.
• Supported formats depend on the upstream. mp3, mp4, m4a, wav and webm are common.

Two: TTS, text to speech

The standard OpenAI shape:

POST /v1/audio/speech
{"model":"tts-1","input":"text to synthesise","voice":"alloy"}

The response is an audio binary stream, not JSON.

Key points:

• The response Content-Type is audio/mpeg. Parsing it as JSON fails outright.
• A relay site's billing may count characters rather than tokens, so confirm in the dashboard.
• Some sites route TTS to a completely different upstream, a domestic vendor for instance, so the voice list does not match the official one.

Three: Realtime

A WebSocket long connection. This one has the lowest support rate on relay sites, because:

• forwarding WebSockets is more involved than HTTP, since it requires holding a long connection and a bidirectional stream;
• the billing model differs from HTTP requests;
• most implementations built on the One API family either do not support it or support it incompletely.

If your product needs realtime voice conversation, verify it separately before launch. Do not assume it works.

Four things you must test

1. Does the interface shape work at all

Start by curling the multipart STT endpoint directly:

curl -s https://<domain>/v1/audio/transcriptions \
  -H "Authorization: Bearer $KEY" \
  -F file=@test.mp3 -F model=whisper-1

Criterion: a {"text": "..."} structure comes back, and the transcript matches the audio.

When it fails, read the error type:

• 415 or 400 mentioning Content-Type → the gateway does not support multipart. This is the most common cause of failure.
• 404 → the endpoint does not exist.
• 200 with an empty text field → transcription was skipped, another silent failure and one worth watching for.

2. File size and duration ceilings

Start with a small file and step up through 5MB and 10MB. Record the failure point.

Why it matters: typical speech input is a recording several minutes long, which easily exceeds some sites' limits, and those limits are frequently undocumented.

3. Audio format coverage

Convert one piece of audio into mp3, wav, m4a and webm and test each.

Why it matters: the browser's MediaRecorder outputs webm/opus by default. If your front end uses that while the site supports only mp3, it fails in real use — but your curl test used mp3, so you never saw it.

This is a textbook "passes the test, fails in production" scenario.

4. TTS voices and quality

• Voice list: the official set is fixed, and a site's may differ.
• Actual audio quality: some sites use a cheap upstream and produce audio with odd sample rates or loudness.
• Long text: TTS usually has a per-call character limit. Exceeding it either errors or truncates, and truncation is worse.

Confirm the billing basis separately

Speech billing works nothing like text:

Confirm the basis in the site's dashboard, because "multiplier" means something entirely different for speech. Some sites do not publish speech pricing at all, and in that case asking the operator beats guessing.

One practical recommendation

Use a separate key for speech, if the site supports multiple keys.

The reason: speech failure modes — large files, long durations, multipart — differ from text, and mixing them on one key makes the usage curve hard to read. Kept separate, a speech problem is immediately visible in the usage figures.

Conclusion

Speech endpoints are noticeably less mature on relay sites than text endpoints. If your project uses speech:

1. Test during selection, not halfway through development.
2. Focus on four things: multipart support, file size, webm format and response type.
3. If a site does not support it, do not count on "support coming later". Forwarding a speech endpoint is substantially different from forwarding text, and many sites have no intention of doing it.

Our listing data is built mainly from text-oriented probing, /v1/models and homepage reachability, and does not include measured speech capability. This one you have to verify yourself.