Testing the recording lifecycle APIs for capacity planning. The goal is to determine the maximum sustainable throughput for starting and retrieving recording metadata before hitting platform limits.
Environment details:
- Genesys Cloud US1
- JMeter 5.6
- Service Account with
recording:readandrecording:write - Target:
/api/v2/recordings/jobs/startand/api/v2/recordings/jobs/{id}
Initial tests with 50 concurrent threads show stable 200 OK responses. Average latency is around 450ms. When increasing concurrency to 200 threads, the error rate spikes. Approximately 30% of requests return HTTP 429 Too Many Requests. The Retry-After header suggests a 10-second wait.
Reducing the rate to 100 threads per minute keeps errors below 1%, but this feels low for a production environment expecting high call volumes. The documentation mentions soft limits on recording job creation, but specific numbers are hard to find.
Also noticing that retrieving large recording lists via /api/v2/recordings/search times out when the size parameter exceeds 1000. Is there a recommended pagination strategy for high-volume archival checks? Using JMeter to simulate nightly cleanup jobs.
The 429 errors seem to reset quickly, but the jitter in response times is causing issues in our load test assertions. JMeter threads are failing due to strict response time expectations. Relaxing the assertions hides the problem but does not solve the underlying throughput bottleneck.
Looking for best practices on pacing API calls for recording management. Should we implement exponential backoff in the JMeter script, or is there a configuration change on the Genesys side? The current setup uses a simple constant throughput timer.
What is the correct way to configure JMeter pacing to avoid 429 errors on recording APIs while validating true system capacity?