Is it possible to configure higher throughput for the real-time conversation analytics endpoints when running automated bot load tests? We are currently stress-testing a NICE CXone virtual agent setup using JMeter 5.6.2. The goal is to simulate 500 concurrent chat sessions hitting the bot simultaneously to measure queue latency and bot response times.
The test environment is deployed in the AWS US-East region, but we are executing the JMeter scripts from our Singapore office (Asia/Singapore timezone). We are using the standard OAuth2 client credentials flow to obtain tokens. The issue arises when we try to pull real-time metrics to verify that sessions are actually being processed by the bot engine.
Specifically, when we hit the /api/v2/analytics/conversations/details/realtime endpoint with even just 50 concurrent threads polling every 2 seconds, we start seeing immediate 429 Too Many Requests errors. The response headers indicate a retry-after value, but our test logic cannot handle dynamic backoff easily without failing the overall test suite. We checked the rate limits documentation, and it seems the limit for analytics endpoints is quite strict compared to the core messaging APIs.
We have tried increasing the polling interval to 5 seconds, which reduces the 429s but doesn’t eliminate them completely under high concurrency. We also attempted to batch requests, but the API does not seem to support batching for this specific endpoint. The bot flows themselves are handling the load fine, as seen in the admin dashboard, but our ability to validate this programmatically is blocked by the API rate limits.
Are there specific headers or parameters we are missing to optimize these calls? Or is there a recommended way to handle real-time monitoring during high-volume load tests without hitting these walls? How can we bypass or manage the 429 rate limits on /api/v2/analytics/conversations/details/realtime during high-concurrency bot load testing?