Quick question about the Screen Recording API behavior under extreme load. We are currently executing a stress test to validate the platform’s ability to handle high volumes of concurrent screen recording sessions initiated via the REST API. The test environment is a Genesys Cloud instance in the APAC region, and we are using JMeter to simulate 200 concurrent agents initiating recordings simultaneously. The JMeter script hits the /api/v2/recordings/screen/records endpoint with the appropriate applicationId and userId parameters. The initial burst of requests succeeds, returning 202 Accepted status codes. However, as the concurrency scales up and the system attempts to process the recording metadata, a significant portion of the subsequent requests start failing with HTTP 403 Forbidden errors. The error payload indicates error_code: “permission_denied”, which is unexpected since the service account used for the load test has the Recording:Screen:Read and Recording:Screen:Write permissions granted at the organization level. We have verified that the OAuth2 tokens are valid and not expiring during the test window. The issue seems to correlate with the rate of request submission rather than a genuine permission issue, suggesting a potential rate-limiting mechanism or a transient state where the permission cache is not being updated fast enough for the burst traffic. We are observing this behavior consistently when the request rate exceeds 50 requests per second per tenant. The WebSocket connections for the actual screen data stream remain stable, but the API calls to manage the recording state fail. We need to understand if there is a hidden rate limit on the screen recording API endpoints that is not documented in the standard API reference, or if this is a known issue with permission validation under high concurrency. Any insights into how to properly tune the JMeter thread groups to avoid triggering this false positive 403 error would be appreciated.