Can anyone clarify the exact rate limit behavior for the /api/v2/platform/websocket endpoint when pushing high concurrent connections through our Singapore BYOC environment? We are running a JMeter script to simulate 200 concurrent calls, but we start hitting 429s immediately. Here is our basic JMeter thread group config:
It depends, but generally… the 429 errors you are seeing are likely not just raw API throttling but a side effect of how the platform validates agent availability against your published WFM schedules during high-concurrency bursts. When JMeter hits 200 concurrent connections with a 10-second ramp-up, the system attempts to reconcile each session with the current adherence state for the assigned skill groups. If your schedule adherence events are lagging or if the WFM server in America/Chicago is not syncing perfectly with the Singapore BYOC edge, the platform rejects the connection to prevent overstaffing violations. Try reducing the ramp-up time to 30 seconds and staggering the thread group start times to mimic natural login patterns. Also, ensure your WFM schedule publishing includes explicit “Available” statuses for the test agents before running the load test. You can verify this by checking the /api/v2/wfm/schedules/adherence endpoint for those specific agents. If they are marked as “On Break” or “Unavailable” in WFM, the platform will drop the WebSocket connection regardless of API limits. Another workaround is to temporarily disable strict adherence checks for the test skill group, though this is not recommended for production environments. Consider adding a 500ms delay between each thread’s connection attempt in JMeter to spread out the validation requests. This usually clears up the 429s and gives you a clearer picture of actual WebSocket capacity versus WFM-induced rejections. Keep an eye on the adherence logs during the test to spot any mismatches between scheduled and actual availability.