Stream audio for a single content

Stream the audio of a single content in the generation task (located by metadata.contents array index) as it is produced.
The only difference from the whole-task streaming endpoint is granularity: no multi-segment concat, only the one clip for that index is fetched.

Response branches

That content's audio already exists (finished audio has landed in storage) → 302 redirect to the finished audio URL.

Task status is processing and the upstream stream URL for that index is ready → return an MP3 byte stream.

Task status is not processing, or the upstream stream URL is not yet ready → JSON error STREAM_NOT_READY.

Note one behavioral difference from the whole-task streaming endpoint: the whole-task endpoint accepts both processing and generated; this endpoint only accepts processing.

Byte stability and Range

Shares the same session mechanism as the whole-task streaming endpoint (the session key additionally includes contentIndex), with the same full support for Range / If-Range / HEAD / 206 / 416.
Likewise, a JSON error body is returned only if the failure happens before any bytes have been sent.

Audio output parameters (no tunable parameters)

Output container / encoding is fixed as MP3 (Content-Type: audio/mpeg); the endpoint does not accept format / bitrate / sampleRate parameters.

Regular concat path: every segment is fed into the same libmp3lame pipeline and re-encoded at a fixed bitrate of 320 kbps (routes/generate/streaming.js:220-221). That pipeline does not explicitly set a sample rate; sample rate is inherited from the upstream segments.

Passthrough path: a single-content instruct/design progressive stream skips ffmpeg entirely, bytes are forwarded as-is (routes/generate/streaming.js:861-869). That path requests 24 kHz MP3 from upstream (routes/generate/streaming.js:842), so this path's output is neither 320 kbps nor 44.1 kHz.

interval silence-fill segments are encoded separately from 44.1 kHz / stereo PCM into 320 kbps MP3 (routes/generate/streaming.js:391-394,421).

Does not return X-Reecho-Audio-Id / X-Reecho-Response-Data

These two response headers exist only on the direct_stream: true direct-return branch of POST /api/tts/generate (routes/generate/tts.js:1789-1798)
and the equivalent branch of simple-generate (routes/generate/tts.js:1321-1322). Those are the only two write sites in the whole repo; they do not exist in routes/generate/streaming.js,
so billing information (credit_used / billing / estimatedDuration) cannot be obtained from this endpoint's response headers — use the generation-task detail endpoint instead.

Auth

Same as the whole-task streaming endpoint: hits the app.js:261 allowlist; only the ?auth= static token is accepted.

Error responses take the shape { status, code, message, requestId? }. code is always the parent code — sub codes only change message and never appear in the body. requestId is present only on reportable-tier errors, so use the X-Vocu-App-Request-Id response header when troubleshooting (it is written unconditionally on every response). See the "Errors" document for the full code reference.

Provide your bearer token in the

Authorization

header when making requests to protected resources.

Example:

Authorization: Bearer ********************

Request Code Samples

Shell

JavaScript

Java

Swift

PHP

Python

HTTP

Objective-C

Ruby

OCaml

Dart

Responses

🟢200成功

audio/mpeg

返回该 content 的 MP3 音频流。状态码与响应头语义同整条流式接口（200 chunked / 200 + Content-Length / 206 / 416 / 302）。

Headers

Bodyaudio/mpeg

Example

{}

🟠400请求有误

🟠401没有权限

🟠403禁止访问

🟠404记录不存在

🟠429