Context:
We are currently validating the capacity of the Digital Messaging channel in the US1 environment. The goal is to determine the maximum throughput for incoming chat sessions before the system starts rejecting connections. We are using JMeter 5.6 to simulate a burst of concurrent users initiating chats via the /api/v2/conversations endpoint. The test plan creates 100 concurrent threads, each sending a POST request to start a new chat session with a specific routing configuration. We are using the standard OAuth2 client credentials flow for authentication, ensuring tokens are refreshed before expiration. The Architect flow is a simple direct route to an agent group with no complex logic or external integrations.
Question:
Need some help troubleshooting why we are seeing HTTP 429 Too Many Requests errors after only 15 concurrent sessions are established. The error response body indicates that the rate limit has been exceeded for the application. However, the documentation suggests that the rate limit should be higher for conversation creation. We have verified that the requests are being sent at a rate of one per second per thread, which seems well within reasonable limits. The 429 errors occur consistently when the number of active conversations exceeds 15, regardless of whether the agents are available or not. We are not seeing any 500 Internal Server Errors, which suggests the backend services are healthy, but the gateway is throttling the requests. Is there a specific configuration in the Architect or the Application settings that limits the number of concurrent chat initiations? We have checked the application’s rate limit settings, but they appear to be set to the default values. Any insights into how to increase this limit or how to structure the test to avoid hitting this threshold prematurely would be appreciated. We want to ensure that our system can handle peak load without dropping customer chats.