Encountering 429 Too Many Requests errors when scaling Predictive Routing outbound campaigns via the REST API on US1. The load test uses JMeter 5.6 to simulate concurrent call initiations through /api/v2/predictiverouting/campaigns/{campaignId}/preview-calls and /api/v2/predictiverouting/campaigns/{campaignId}/calls. At 300 concurrent threads, the error rate spikes to 45% within 10 minutes. The response headers show retry-after values between 2 and 5 seconds, but our retry logic with exponential backoff fails to recover the throughput. The environment is US1, using Genesys Cloud API SDK version 4.2.1 for Java. We are not hitting the global account limit of 10,000 calls per day, but the burst capacity seems constrained. The campaign is configured with a dialing method of Predictive and a power factor of 2.0. The target list contains 50,000 contacts, and the script is a simple IVR menu with no complex logic. The error logs show consistent 429 responses with the message “Rate limit exceeded for predictive routing calls.” We have verified that the API keys have the correct scopes: predictiveRouting:campaigns:view and predictiveRouting:campaigns:edit. The issue persists even when reducing the concurrent threads to 150, where the error rate drops to 15% but throughput remains below the expected 50 calls per minute. The Architect flow is standard, with no custom integrations or external webhooks that could cause latency. The SIP trunks are configured with a capacity of 1,000 channels, and the utilization during the test is less than 10%. We suspect the issue is related to the API rate limits for predictive routing endpoints, but the documentation does not specify the exact limits for concurrent call initiations. Could someone clarify the rate limits for /api/v2/predictiverouting/campaigns/{campaignId}/calls and suggest a way to handle the 429 errors more effectively? We need to achieve a sustained throughput of 100 calls per minute for our capacity planning. The current retry strategy is not sufficient, and we are looking for best practices to optimize the API calls for high concurrency. Any insights into the underlying rate limiting mechanism or alternative approaches to scaling predictive routing campaigns would be appreciated. The test runs from 9 AM to 5 PM EST, and the error pattern is consistent across multiple test cycles. We have also checked the system health dashboard, and all services are reported as healthy. The issue is isolated to the predictive routing API endpoints, as other APIs like archiving and reporting work without issues. We are using a dedicated load testing environment with no other active campaigns to eliminate interference. The JMeter configuration includes a constant throughput timer set to 300 requests per minute, and the HTTP request sampler is configured with keep-alive connections. The response times for successful calls are under 200 milliseconds, indicating that the network latency is not a factor. The problem seems to be strictly related to the API rate limits imposed by Genesys Cloud on predictive routing endpoints. We have tried adjusting the thread group settings and using different retry intervals, but the 429 errors remain a bottleneck. Any guidance on how to structure the API calls to avoid hitting the rate limits or how to interpret the retry-after headers more effectively would be helpful. We are also interested in knowing if there are any known issues with the SDK version 4.2.1 related to predictive routing API calls. The test data is static, and the contact list is refreshed daily to ensure no duplicate calls. The campaign settings are identical across all test cycles, and the only variable is the number of concurrent threads. We have also monitored the WebSocket connections, and they remain stable throughout the test. The issue is reproducible in the US1 environment, and we have not tested it in other regions yet. Any advice on how to proceed with the load testing or how to contact Genesys support for further assistance would be appreciated. We are under pressure to complete the capacity planning by the end of the month, and this issue is blocking our progress. Thank you in advance for any help or suggestions.