Screen Recording API 429s during high-concurrency load test

Hitting 429 Too Many Requests immediately when blasting GET /api/v2/recording/recordings?status=COMPLETED via JMeter 5.6.2. The rate limit header says X-RateLimit-Remaining hits zero after just 15 requests per second. We are running this from a Singapore-based EC2 instance to validate how the platform handles concurrent screen recording metadata fetches during peak load. The environment is Genesys Cloud US2, and we are testing with 50 concurrent threads hitting the endpoint every 100ms.

Is there a specific caching strategy or pagination trick we should use to avoid hitting the global rate limit for recording queries? The docs mention standard rate limits, but screen recording APIs seem to throttle harder than voice recording ones. We need to pull status updates for thousands of concurrent screen shares, and the current approach is failing hard. Any insights on increasing throughput or batching these requests would be appreciated. We are trying to figure out if this is a hard limit or if we are doing something wrong with the query parameters.