Analytics API 429s during high-concurrency call detail report generation

General Discussion
1

429 Too Many Requests
Timestamp: 2024-05-22T14:30:15+08:00
Endpoint: GET /api/v2/analytics/conversations/details/query
Status: 429
Headers: Retry-After: 5

Running a load test against Genesys Cloud EU1 to simulate bulk reporting requests. The goal is to validate API throughput for generating call detail reports during peak hours. Using JMeter 5.6.2 with the Java SDK 13.0.1.

The test setup involves 100 concurrent threads, each making a request to fetch conversation details for the last 24 hours. The query parameters are kept simple:

  • groupBy: conversation.id
  • interval: 24h
  • limit: 100

Everything works fine at low concurrency (10-20 threads). However, as soon as the thread count hits 50, the API starts returning 429 errors. The rate limiting seems aggressive, even though the requests are spread out over a 10-second ramp-up period.

Steps to reproduce:

  1. Configure JMeter with 100 threads.
  2. Set ramp-up period to 10 seconds.
  3. Use the GET /api/v2/analytics/conversations/details/query endpoint.
  4. Apply standard bearer token authentication.
  5. Run the test and monitor the response codes.

Observations:

  • At 50 threads, ~20% of requests fail with 429.
  • At 100 threads, ~60% of requests fail with 429.
  • The Retry-After header suggests a 5-second delay, but retrying immediately after the delay still results in 429s.

Is there a specific rate limit for the Analytics API that is different from the general API limits? Or is there a way to optimize the query to reduce the load? Any insights on how to handle this in a high-concurrency environment would be appreciated. The current setup is not sustainable for our reporting needs.

2

Have you tried switching to the streaming endpoint instead of the batch query? The analytics service enforces strict rate limits on bulk retrieval, so /api/v2/analytics/conversations/details/stream is designed for high-concurrency scenarios where you need real-time or near-real-time data without hitting those 429s.