I’ve spent hours trying to figure out why the screen recording endpoint triggers 429 Too Many Requests when concurrent throughput exceeds 5 requests per second. Environment: Genesys Cloud US1. Tool: JMeter 5.6. Endpoint: POST /api/v2/recording/screenrecordings. The error response body contains {“code”:“too_many_requests”,“message”:“Rate limit exceeded”}. This happens consistently after 10 seconds of steady load. Our load test script uses 10 threads with a ramp-up period of 1 second. Each thread sends a request to start a screen recording session. The requests are spaced 200ms apart to avoid immediate saturation. However, the rate limiting kicks in regardless of the spacing. We have verified that the authentication tokens are valid and not expired. The issue persists even when we reduce the concurrent threads to 5. This suggests that the rate limit is not based on concurrent connections but on a global counter or a specific endpoint throttle. We need to understand the exact rate limit for this endpoint to adjust our JMeter configuration accordingly. Is there a way to increase the rate limit temporarily for testing purposes? Or should we implement a retry mechanism with exponential backoff in our JMeter script? Any insights into the expected throughput for screen recording API calls would be helpful. We are planning a large-scale validation of our agent desktop performance and need to ensure that the recording service can handle the load without dropping requests. The current behavior blocks our ability to proceed with the full capacity planning exercise. We have checked the Genesys Cloud documentation but it does not specify the exact rate limits for the screen recording endpoints. Any guidance on this matter would be greatly appreciated. We are currently stuck and need to resolve this before our next testing cycle begins next week. The timezone for our testing is America/New_York and we are running the tests during business hours to simulate real-world conditions.