Can anyone explain why the Outbound Campaign endpoints are throwing 429 Too Many Requests errors when JMeter 5.6.2 hits just 15 concurrent threads? The specific endpoint causing issues is POST /api/v2/outbound/campaigns. We are testing from our Asia/Singapore lab against a Genesys Cloud BYOC Edge 24.2 environment. The goal is to simulate bulk campaign creation during peak load scenarios, but the rate limiting seems aggressive for a beginner setup. We are not even close to the documented global limits, yet the throttling kicks in almost immediately after the ramp-up phase starts.
The JMeter script is straightforward. It uses a Thread Group with 15 threads, a loop count of 10, and a constant throughput timer set to 50 samples per minute. The request payload includes standard campaign fields like name, type, and list IDs. Authentication is handled via OAuth 2.0 with a single access token shared across threads for simplicity, which we know might not be best practice but should not cause immediate 429s on write operations. The response headers consistently show the Retry-After value, but the error persists even after waiting the specified duration.
We have checked the Architect API limits and the Analytics API limits, which we have tested previously with similar results. However, the Outbound API seems to have a different throttling mechanism or lower threshold. The error message in the response body is standard: “Rate limit exceeded. Please retry after the specified time.” There are no detailed logs provided in the response to indicate which specific sub-limit is being hit. We are trying to determine if this is a per-user limit, per-organization limit, or a global endpoint limit.
Any insights on how to structure the JMeter test to respect the Outbound API rate limits without hitting 429s at such low concurrency would be appreciated. We are also open to suggestions on whether we should be using a different endpoint or method for bulk campaign creation. The current setup works fine for single-threaded tests but fails consistently under any concurrent load. We want to ensure our load testing methodology is valid before proceeding with larger scale tests.