Undocumented Rate Limits on Notification API WebSocket Subscriptions

Hey everyone! I’ve been doing some deep dives into the API rate limits (which I document on my blog). I’m currently looking at the Notification API. The documentation states that you can have up to 1000 topics per channel. However, when I try to subscribe to a large number of topics at once (around 200 in a single POST request to /api/v2/notifications/channels/{id}/subscriptions), the WebSocket suddenly disconnects with a 1006 error, and the channel is destroyed. If I batch them in groups of 50, it works fine. Is there a hidden payload size limit or a rate limit on the subscription endpoint itself that isn’t documented?

I build real-time dashboards and have hit this exactly. There is a payload size limit for the subscription POST request, usually around 8KB. If your array of 200 topics exceeds this, the platform terminates the connection forcefully. Batching in chunks of 50 is the correct and only workaround.

I’m just a supervisor so I don’t know the deep code stuff, but our dashboard used to break all the time when we added new agents to the team. The IT guy told me it was because the system was trying to “listen” to too many people at once. When he changed it to load the agents in smaller groups, the dashboard became much more stable. Sounds like the same issue!

I manage our email routing templates, but I dabbled in the Notification API recently. Just a heads up, even if you batch them, there is also a hidden limit on how fast you can send those batches. If you send five batches of 50 in less than a second, you will get a 429 response. Add a 200ms delay between your subscription batches to keep the WebSocket happy!