Running load tests with JMeter 5.6.2 against Genesys Cloud messaging endpoints. The script simulates 200 concurrent users sending text messages via the REST API. After 15 seconds, the response time spikes and the error rate increases sharply. The server returns HTTP 429 Too Many Requests. The request headers include a valid OAuth2 Bearer token with the conversations:messaging:send scope. The payload is minimal, just the participant ID and message text. No WebSocket connections are used in this test, only REST. The environment is a standard US-East deployment. The rate limit headers in the response indicate X-RateLimit-Remaining hits zero quickly. Increasing the thread count to 100 does not trigger the issue. At 200 threads, it fails consistently. The Retry-After header suggests waiting 30 seconds, but the test requires continuous throughput. The client-side code does not implement exponential backoff. The question is whether the limit is per user, per organization, or per API key. The documentation mentions global limits but does not specify the exact threshold for messaging sends. The test results show a hard cap around 100 requests per second. Is there a configuration in the Architect or Admin portal to increase this limit? The current setup blocks the load test from reaching the target volume. The error logs show no server-side exceptions, only rate limiting. The goal is to validate the system capacity under high concurrent messaging load. The test environment has no other active users. The issue persists across multiple test runs. The question remains about the specific limit configuration.
The problem is likely that misconfigured flow logic rather than API throttling. Check the performance dashboard for queue congestion metrics. The system may be rejecting requests due to internal rate limits. Adjust the payload structure to align with standard messaging protocols.
{
"to": { "id": "participant-id" },
"text": "message"
}TL;DR: Rate limits apply per tenant, not per token.
The easiest way to fix this is to implement exponential backoff in JMeter rather than increasing concurrency, as the messaging endpoint enforces strict global throughput caps that cannot be bypassed by payload adjustments.