Why is this setting causing immediate rate limiting when querying interaction data at scale?
Running a load test to validate our reporting pipeline capacity. The goal is to pull historical interaction data for a custom dashboard using JMeter. When the thread count reaches 50 concurrent users hitting GET /api/v2/analytics/interactions/summary/voice, the server responds with HTTP 429 Too Many Requests. The documentation mentions standard rate limits, but the drop-off seems instantaneous and aggressive compared to other endpoints like Architect flows.
The environment details are as follows:
- Tool: JMeter 5.6.2
- Endpoint:
GET /api/v2/analytics/interactions/summary/voice - Parameters:
dateFrom=2023-10-01,dateTo=2023-10-02,groupings=queueId - Concurrent Threads: 50 (ramp-up 5s)
- Result: 100% failure rate with 429 status code after first few requests
- Genesys Cloud Region: us-east-1
The manual API call works fine. The issue appears only under concurrent load. I checked the response headers and see Retry-After: 1, but adding a constant timer in JMeter does not help because the limit seems to be per-user or per-tenant burst limit rather than a simple per-minute quota.
Is there a specific configuration in Genesys Cloud admin that controls the burst capacity for Analytics APIs? Or is this a hard limit for non-premium tenants? The standard error payload is:
{
"code": "tooManyRequests",
"message": "Rate limit exceeded",
"status": 429
}
I need to understand if this is expected behavior for load testing or if we need to adjust our polling strategy. Any advice on how to structure the JMeter script to respect these limits without failing the entire test suite?