GET /api/v2/analytics/interactions/summary 429s at 10 RPS

General Discussion
1

I’m curious as to why the analytics summary endpoint is throttling so aggressively during our baseline load tests? We are trying to establish a baseline for dashboard refresh rates but hitting hard walls immediately.

  • Endpoint: GET /api/v2/analytics/interactions/summary
  • Query Params: dateRange=last24hours, groupBy=agent, metricNames=wrapup.time,talk.time
  • Tool: JMeter 5.6.2
  • Environment: Genesys Cloud BYOC Edge 24.1.0 (Asia/Singapore)
  • User Agent: JMeter/5.6.2 (linux)

We started with a gentle ramp-up. The goal was to simulate 50 agents refreshing their performance dashboards every 60 seconds. This translates to roughly 0.83 requests per second per user, or about 42 RPS total across the thread group. However, the errors start appearing way before that.

  • At 10 RPS, the response time jumps from 200ms to 4.5s.
  • At 12 RPS, we start seeing 429 Too Many Requests errors in about 30% of the samples.
  • By 15 RPS, 100% of the requests are failing with 429s.

The response headers for the 429s include:

  • Retry-After: 5
  • X-RateLimit-Remaining: 0
  • X-RateLimit-Limit: 600

Wait, 600? The limit header says 600, but we are failing at 15. Is this a per-user limit or a per-tenant limit? Our JMeter config uses a single admin user for authentication via OAuth2 Client Credentials flow. If it is per-user, why is it so low? If it is per-tenant, shouldn’t we be able to hit higher numbers before hitting the wall?

We tried adding a Retry-After handler in JMeter but it just slows down the test to a crawl. We need to know the actual throughput ceiling for this endpoint. Is there a different endpoint we should be using for high-frequency polling? Or is this just a hard cap for analytics queries to prevent backend overload?

Any insights on how to structure the requests to avoid this? We are not doing complex aggregations, just simple group-by-agent summaries. This seems overly restrictive for a basic load test scenario.