error: 429 too many requests
endpoint: /api/v2/outbound/campaigns/{campaignId}/preview
region: ap-southeast-1
hey, stuck on this again. running a jmeter script to simulate outbound dialing throughput. the goal is to see how the preview endpoint handles concurrent requests before we scale up the actual campaign.
with just 30 concurrent threads, the api starts returning 429 errors. i checked the rate limit docs but it says the limit is higher for this endpoint. maybe i am missing something about the burst capacity.
the request body is minimal, just the contact id and campaign reference. no heavy payload. the response time is under 200ms when it works, but the 429s are consistent after the 10th concurrent request.
is there a specific header i need to set for outbound api calls? or is this a known issue in the singapore region? trying to validate our load testing strategy before the big push next week. any insights would be helpful.
This looks like a rate-limiting constraint rather than a genuine throughput failure for the preview endpoint. The outbound API enforces strict request caps per account to protect system stability, and thirty concurrent threads likely exceed the default threshold for preview operations. It is advisable to reduce the thread count significantly, perhaps to five or ten, and implement a delay between requests in the JMeter script to respect the rate limits. Alternatively, consider using the standard campaign launch mechanism for load testing, as the preview endpoint is not designed for high-concurrency scenarios. Monitoring the response headers for X-RateLimit-Remaining can provide visibility into the current quota status. Adjusting the test parameters to align with documented API limits will yield more accurate performance data without triggering throttling mechanisms.
Ah, yeah, this is a known issue… The outbound API enforces strict rate limits per account, often lower than standard REST endpoints, to protect dialer stability. Thirty concurrent threads will almost certainly trigger throttling on preview operations. The suggestion above to reduce thread count is correct, but you should also implement exponential backoff in your JMeter script. Instead of fixed delays, use the Random Timer with a Gaussian distribution to mimic human-like pacing. For automated testing, consider using the Genesys Cloud CLI with a retry policy built into your CI/CD pipeline. Here is a sample GitHub Actions step for rate-limit-aware execution:
- name: Run Outbound Preview Test
run: |
for i in {1..30}; do
curl -X GET "https://api.mypurecloud.com/api/v2/outbound/campaigns/$CAMPAIGN_ID/preview" \
-H "Authorization: Bearer $GC_TOKEN" \
--retry 3 --retry-delay 2
done
This approach respects the 429 headers and avoids overwhelming the ap-southeast-1 region. Always check the Retry-After header in the response for precise wait times.