Configuration is broken for some reason…
Trying to validate API throughput for outbound campaign updates under high concurrent call volumes. Using JMeter 5.6 with 50 concurrent threads against /api/v2/outbound/campaigns on Genesys Cloud US1. The goal is to simulate dynamic campaign state changes during peak load.
JMeter run starts and immediately returns 429 Too Many Requests: Rate limit exceeded. This happens even with simple PATCH requests to update paused status. The headers show X-Rate-Limit-Remaining: 0 after just 10 requests.
Environment details:
Genesys Cloud US1JMeter 5.650 concurrent threadsRamp-up: 0 secondsLoop count: 1
The test hits 50 threads and returns 429 Too Many Requests. Why does this setting trigger rate limits immediately? I am trying to understand the capacity planning for outbound API endpoints. The documentation mentions rate limits per organization but does not specify exact numbers for /api/v2/outbound/campaigns.
Is there a way to increase the limit for load testing purposes? Or should I reduce the concurrency? The current setup mimics our expected production load where we update multiple campaigns simultaneously based on real-time analytics.
Looking for advice on handling rate limits when pushing outbound config changes at scale. Any suggestions on JMeter configuration to respect these limits while still validating throughput? The test fails completely at 50 threads which seems low for a production environment.
Need to ensure our load patterns do not break the outbound dialing functionality. The error response includes a retry-after header but JMeter does not automatically wait. Should I implement a custom listener for this?
Any help with API rate limits for outbound endpoints would be appreciated. The goal is to validate that our system can handle the concurrent updates without hitting 429 errors during peak hours.