Short answer: your request is simply taking longer than the client-side timeout.
The ElevenLabs Node SDK enforces a client-side HTTP timeout (defaults to 60s). You can raise it with timeoutInSeconds, but if generation exceeds that value the SDK aborts with ElevenLabsError: "timeout". (github.com)
The POST /v1/text-to-speech/:voice_id convert endpoint returns only after the full audio is generated. For long inputs this can take many minutes—models allow up to 10k–40k characters, roughly ~10–40 minutes of audio. A 300s (5 min) timeout will still fail for longer clips. (elevenlabs.io)
What to do instead (recommended by our docs):
Use the streaming TTS endpoint (/v1/text-to-speech/:voice_id/stream). It sends audio incrementally over HTTP chunked transfer, avoiding a single long-running request. The SDK exposes text_to_speech.stream for this. (elevenlabs.io)
Or split long text into multiple shorter requests (the models page explicitly recommends chunking for longer content). (elevenlabs.io)
Reference docs:
TTS convert endpoint: POST /v1/text-to-speech/:voice_id. (elevenlabs.io)
TTS stream endpoint: POST /v1/text-to-speech/:voice_id/stream. (elevenlabs.io)
Model character limits and approximate durations. (elevenlabs.io)
Short answer: I can’t find any official documentation that sets a 60‑second maximum timeout for the Text‑to‑Speech REST endpoints. The only timeout explicitly documented is for the WebSocket streaming endpoint: inactivity closes the socket after 20 seconds by default, and you can raise that via the inactivity_timeout query parameter up to a maximum of 180 seconds. (help.elevenlabs.io)
What you can do to avoid client-side timeouts on long generations:
Use the HTTP streaming endpoints so audio is returned progressively instead of waiting for a single long response. This is the recommended approach for longer inputs. (elevenlabs.io)
If you need timestamps as you stream, use the stream/with-timestamps endpoint. (elevenlabs.io)
Alternatively, use the WebSocket streaming API (and, if needed, set inactivity_timeout up to 180s). (elevenlabs.io)
For very long texts, split the input and (if you want continuity) follow the guidance to segment content and use streaming. (elevenlabs.io)
Note: The JavaScript SDK’s timeoutInSeconds option and its limits aren’t documented publicly, so I can’t confirm its behavior or any max value from the official docs. If you’re consistently seeing ~60s timeouts with convert(), switching to the streaming endpoints or WebSockets is the documented way to handle longer runs. (elevenlabs.io)
lyric thorn
clever oar