Anyone know why the Messaging API returns a 429 Too Many Requests error when scaling concurrent sessions beyond 10 threads in JMeter 5.6? The load test targets the Genesys Cloud US1 environment. The script is configured to send initial messages to /api/v2/conversations/messages with a valid OAuth token that has the appropriate scope for messaging. The token is refreshed every 50 minutes as per standard practice. The issue appears specifically when the throughput exceeds 10 requests per second. The error response includes a Retry-After header with a value of 1 second, but increasing the delay between requests does not resolve the issue at higher thread counts. The JMeter configuration uses HTTP Request defaults with keep-alive enabled and a connection timeout of 5000ms. The goal is to validate the system’s capacity for handling high-volume digital messaging scenarios, similar to peak call volumes but for text-based interactions. The environment is configured with standard digital channel limits, and no custom rate limiting policies are applied at the tenant level. The error occurs consistently across multiple test runs, indicating a systematic limitation rather than a transient network issue. The logs show that the requests are reaching the Genesys Cloud servers, as evidenced by the 429 response code, but the data is not being processed. The issue is critical for capacity planning, as the business expects to handle up to 100 concurrent messaging sessions during peak hours. The current setup prevents accurate load testing beyond 10 threads, which is significantly lower than the expected capacity. The JMeter script includes proper header configurations, including Content-Type: application/json and Authorization: Bearer . The payload size is minimal, containing only the necessary fields for message creation. The issue persists even when reducing the payload size and simplifying the request structure. The environment details include Genesys Cloud US1, JMeter 5.6, and a standard digital channel configuration. The problem is isolated to the messaging API, as other APIs such as WFM and Analytics do not exhibit the same behavior under similar load conditions. The expectation is that the system should handle at least 50 concurrent messaging sessions without triggering rate limits, based on the documentation and similar experiences with voice channels. Any insights into the specific rate limits for the messaging API or recommendations for configuring JMeter to avoid these errors would be appreciated. The focus is on understanding the technical constraints and optimizing the test configuration to achieve accurate load testing results. The issue is preventing progress in the performance validation phase, as the current limitations do not reflect the expected production load. The goal is to ensure that the system can handle the anticipated volume of digital interactions without degradation in service quality. The current error rate of 100% for requests beyond 10 threads is unacceptable for a production environment. The request is for specific guidance on API rate limits, best practices for load testing digital channels, and potential workarounds to bypass the 429 errors during testing. The environment is stable, and the issue is reproducible, making it a reliable case for analysis. The expectation is that the community can provide insights based on similar experiences or official documentation regarding digital channel capacity planning.