Transcribe one uploaded audio file
Batch speech-to-text. The audio always travels as an uploaded part, never as a URL: the Router fetches nothing on a caller's behalf. For idempotency the content hash covers the decoded part payload bytes only — no part headers, no boundary bytes — concatenated in part order (request, then audio), so a retry hashes identically no matter what boundary string the client generates. Usage lives in the response body; there is deliberately no STT usage header.
Headers
Required on every POST. The Router persists only the key, a content hash, and the request's execution status — never the content itself. For single-part bodies the content hash covers the raw body bytes exactly as sent; for multipart bodies it covers the decoded part payload bytes only — no part headers, no boundary bytes — concatenated in part order (request, then audio), so per-retry boundary strings never change the hash. Reusing a key with the same hash while the original admission is still live returns request_in_progress (retryable); after dispatch it returns request_already_started with the original request id, because stateless mode cannot replay output; reusing a key with a different hash returns idempotency_conflict. Keys are opaque; the Router imposes no format beyond the length bound, and the normative bound is 256 BYTES — maxLength below counts code points, which JSON Schema cannot avoid, so multi-byte keys hit the byte bound first.
Response
The transcription result.
Changes
Changed in 1 of the 7 revisions of this API.1
- ○
endpoint added
endpoint-added
This revision also has 7 changes that name no endpoint, such as unreferenced schemas being removed. See the revision's changelog
- ○