429 Too Many Requests - Rate limit exceeded for endpoint /api/v2/conversations/messaging
We are hitting a hard wall with our latest stress test for Digital/Messaging channels. The goal is to validate concurrent inbound message throughput on a dedicated BYOC edge before our peak season. We are using JMeter 5.6.2 with a custom script to simulate 500 concurrent users sending messages via the REST API.
The environment is Genesys Cloud v2024.1. We are seeing immediate 429 responses after just 50 concurrent requests, even though the documented rate limit for this endpoint is supposed to be much higher. The error payload returns a standard retry-after header, but the latency spikes are killing our test results.
Steps to reproduce:
- Set up JMeter with 500 threads and a ramp-up period of 60 seconds.
- Configure HTTP Request sampler to POST to /api/v2/conversations/messaging.
- Include valid JSON payload with a unique message ID for each request to avoid idempotency errors.
- Authenticate using a Service Account with full messaging permissions.
- Start the test and monitor the response codes.
We have verified that the Service Account has no additional throttling applied in the admin console. The 429s start almost immediately after the ramp-up reaches 10% capacity. We have also checked the WebSocket connection limits, but since we are using REST for this specific test, that shouldn’t apply.
Is there a hidden rate limit for digital messaging endpoints that isn’t documented? Or is there a specific header we need to include to bypass this? We need to understand if this is a platform limitation or a configuration issue on our end. Any insights into the rate limiting behavior for high-concurrency messaging flows would be appreciated. We are trying to determine if we need to implement a client-side queueing mechanism in our application to handle these spikes.