Script API 429s during high-concurrency JMeter load test

Could someone clarify why the Scripting API endpoints are returning 429 Too Many Requests when I ramp up concurrent users in JMeter to just 50 threads? I am trying to simulate a high-throughput scenario for agent script execution in our Singapore region (us-east-1 api gateway). The load test hits the POST /api/v2/scripts endpoint to trigger script steps based on incoming call data. At low concurrency (5-10 threads), it works fine. Once I hit 50 concurrent requests within a 1-second window, the error rate spikes to 80%.

“Rate limits for the Scripting API are applied per organization and per API key. Exceeding the limit results in a 429 response with a Retry-After header.”

I have checked the Retry-After header, and it suggests waiting 1-2 seconds. However, in a real-time voice scenario, this latency is unacceptable for our performance metrics. Is there a specific rate limit for script execution triggers that I am missing? Or should I be batching these requests differently? I am using the latest JMeter HTTP Request sampler with keep-alive enabled. Any insights on the actual threshold for this endpoint would be helpful.

I typically get around this by implementing exponential backoff with jitter in JMeter. The Script API has strict rate limits per organization, not just per endpoint. Spreading requests out prevents immediate throttling.

Note: Check your specific org’s API rate limit quotas in the admin console.

This is typically caused by the default rate limiter on the scripting endpoint, which caps at 100 req/min per org. Check https://support.genesys.com/s/article/script-api-throttling for the exact limits and how to request a temporary increase for load testing.