Streaming STT (flux-general-en) WebSocket handshake rejected with HTTP 429

[melikedemircii]

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.
• Usage: We do not use the Deepgram SDK. Our service connects to the streaming endpoint directly over a raw WebSocket (Python websockets library), so we handle the handshake ourselves.

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:

1. What was our project's actual configured concurrency limit for Flux streaming during that window?
2. 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?
3. 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.

[deepgram-community[bot]]

Thanks for asking your question. Please be sure to reply with as much detail as possible so the community can assist you efficiently.
_{Consider joining our Discord community for more opportunity to engage with your fellow Deepgram users. You can earn points which can be redeemed for cool stuff by being active in our communities!}

[deepgram-community[bot]]

Hey there! It looks like you haven't connected your GitHub account to your Deepgram account. You can do this at https://community.deepgram.com - being verified through this process will allow our team to help you in a much more streamlined fashion.

[jkroll-deepgram]

Hi @melikedemircii, I see your Flux concurrency was highest (ranging from ~165-190 concurrent streams) on May 30th (UTC), and was also slightly elevated (~100-150 concurrent streams) in the period from June 3rd-4th (UTC). The specific hourly period I see you were over the rate limit of 150 concurrent streams was May 30th 00:00 UTC - May 31th 00:00 UTC. Did you experience any 429s outside of that period? If not, the 429s do seem like expected rate limits due to exceeding 150 concurrent Flux streams. Our growth and enterprise plans offer higher rate limits (doc link).

Deepgram will also still return request IDs when we return 429s, so those request IDs are useful to log for reference and troubleshooting.

[esraari]

Hi team,

When we check the logs for daily requests, we do not see high traffic or unusual request activity, as also shown in the screenshot from the Deepgram usage review, even though usage may have decreased due to this error.

Could you please provide the open socket request IDs within this time window?

I can see the logs on the usage dashboard, but I cannot find the socket IDs that were opened during that period. I am an admin on this project, so you can email me the specific opened socket request IDs that caused the concurrency limit issue so we can investigate further.

Email: esraari@jotform.com
Project ID: 5468b6b1-3f54-4778-9f0a-71dad34ca79d

[jkroll-deepgram]

Hi @melikedemircii, I was able to list your historical 429's by searching your Console usage for requests before May 31, which were status Failed, endpoint /listen, and method streaming: https://console.deepgram.com/project/5468b6b1-3f54-4778-9f0a-71dad34ca79d/usage/logs?start=2026-05-31T19%3A43%3A16.999Z&page=1&status=failed&endpoint=listen&method=streaming

Here's one of those example request IDs for reference: 019e7e23-c020-7f23-be61-cdf8b8d233a1

[esraari]

Hi Deepgram team,

I think there may be a misunderstanding about what we are asking for.

We are not looking for the request IDs of the WebSocket connections that failed with concurrency-limit errors.

What we need is the list of already-open / active WebSocket connections that were occupying our concurrency capacity at the time the limit was hit.

Specifically, could you please check between May 29–30, 2026 (UTC+3) and provide any 10-minute sliding window where our project had around 150 concurrent open WebSocket connections?

For that window, we need the active socket/request IDs that were already open and counted against our concurrency limit.

Project ID: 5468b6b1-3f54-4778-9f0a-71dad34ca79d

This will help us investigate whether some sockets are staying open longer than expected or not being closed properly on our side.

Thanks.

[jkroll-deepgram]

@esraari, we don't persist minute-level concurrency granularity long-term. I can see that your Flux max concurrency per hour was over 150 (ranging from 164 to 189) for every hour from May 30th 00:00 UTC - May 31st 00:00 UTC. On May 31st 00:00 UTC (hourly period), your concurrency dropped to 77.

If you encounter rate limits again, I can check minute-level concurrency on your project for the last 24 hours.

You can also examine your own historical usage with the List Project Requests management API. That will provide the start time and audio duration. However, it doesn't capture complete data including when websockets are open but not receiving audio.