Hi Team,
We're seeing our streaming Speech-to-Text WebSocket connections to the Flux model get rejected with a 429 error during the handshake.
Exact error returned by our client: "server rejected WebSocket connection: HTTP 429"
Details:
- Project ID: 5468b6b1-3f54-4778-9f0a-71dad34ca79d
- Model: flux-general-en (Flux streaming)
- Endpoint: wss://api.deepgram.com/v2/listen
- When: Between 29-30 May 2026 (UTC+3)
- Behavior: The 429 is returned on the WebSocket handshake itself, so the connection never opens.
Our concern:
We were running well below the documented Flux streaming concurrency limit (150 concurrent streams) at the time, so we did not expect to hit a concurrency-based 429.
Questions:
- What was our project's actual configured concurrency limit for Flux streaming during that window?
- Can you check the server-side concurrent-stream count for our project during 29-30 May (UTC+3) and tell us what triggered the 429?
- Could stale/abandoned streams (e.g. clients that disconnected uncleanly) remain counted server-side and inflate our concurrency? If so, what is the timeout before such a stream is released?
Note on request IDs:
Because these requests fail at the WebSocket handshake with HTTP 429, the connection is never established. Deepgram rejects it before a session is created. As a result, no request ID is returned to us for these failed attempts, so we're unable to share one. However we have shared the project id, we can also provide the timestamps of the failures. Please let us know if you need any other information.
Hi Team,
We're seeing our streaming Speech-to-Text WebSocket connections to the Flux model get rejected with a 429 error during the handshake.
Exact error returned by our client: "server rejected WebSocket connection: HTTP 429"
Details:
Our concern:
We were running well below the documented Flux streaming concurrency limit (150 concurrent streams) at the time, so we did not expect to hit a concurrency-based 429.
Questions:
Note on request IDs:
Because these requests fail at the WebSocket handshake with HTTP 429, the connection is never established. Deepgram rejects it before a session is created. As a result, no request ID is returned to us for these failed attempts, so we're unable to share one. However we have shared the project id, we can also provide the timestamps of the failures. Please let us know if you need any other information.