Context:
We are currently validating the throughput of the recording ingestion pipeline in Genesys Cloud under heavy load. The goal is to determine the maximum sustainable rate of concurrent screen recording sessions before we hit platform limits. We are using a custom JMeter script to simulate a burst of 500 virtual agents initiating screen recordings simultaneously via the POST /api/v2/recorder/screen-recordings endpoint.
The environment is set up with standard rate limiting policies. We are observing that as soon as the thread count ramps up past 150 concurrent requests, the API starts returning HTTP 429 (Too Many Requests) errors. The error payload indicates that we have exceeded the per-user rate limit, even though we are using distinct user tokens for each virtual agent in the test script. We have verified that the tokens are valid and not shared.
Interestingly, if we space out the requests with a 500ms delay between each thread, the 429 errors disappear, but this does not reflect our expected production traffic pattern. We need to understand if there is a global rate limit for screen recording initiation that is independent of user-specific limits, or if there is a configuration setting we are missing. We are also seeing some WebSocket connection drops on the client side when the 429 errors occur, which complicates the retry logic in our JMeter script.
Question:
Can anyone clarify if there is a hard cap on the number of concurrent screen recording initiation requests allowed per organization, regardless of the number of unique users? We are trying to optimize our JMeter script to avoid these 429 errors without artificially slowing down the test. Any insights into the rate limiting behavior for the screen recording API would be appreciated. We are currently using the latest version of the Genesys Cloud API client libraries in our test setup.