Script API 429s during load testing

Hey everyone, I’ve run into a really strange issue with Script API 429s during load testing. JMeter is hammering /api/v2/scripts to generate unique scripts for each concurrent agent session, but it’s hitting rate limits immediately. Is there a way to increase the limit or should I be caching these responses differently?

429 Too Many Requests
{“code”:“too_many_requests”,“message”:“Rate limit exceeded”,“status”:429}

My current setup uses a thread group with 500 users, each making a POST request to /api/v2/scripts with a unique script name and content. The requests are sent at a rate of 100 per second. After about 50 requests, I start seeing 429 errors. I’ve tried adding a delay of 100ms between requests, but that doesn’t seem to help much. The Genesys Cloud documentation mentions that the rate limit for this endpoint is 100 requests per second, but it’s not clear if that’s per tenant or per user. I’m assuming it’s per tenant, but I’m not sure. I’ve also tried using the batch endpoint /api/v2/scripts/bulk, but that doesn’t seem to be available for creating scripts. I’m using the Genesys Cloud REST API v2, and my tenant is in the US East region. I’m running the tests from a single EC2 instance in the same region. Any ideas on how to work around this? Should I be using a different approach for generating unique scripts for each agent? I’m open to any suggestions. Thanks in advance!

you need to reconsider the approach of generating unique script objects per session. this pattern creates unnecessary load on the platform infrastructure and quickly triggers rate limiting mechanisms. instead, utilize a single master script resource and leverage variable injection during the flow execution. configure the script once in the admin console and reference it by id in your architect flow. pass dynamic values through the interaction data or user-defined variables at runtime. this method eliminates the need for repeated api calls to the script endpoint. the performance dashboard will show a significant reduction in api latency and error rates when this change is implemented. caching the script object in your local application memory is also an option, but variable injection is cleaner from an architectural standpoint. ensure your load test simulates realistic traffic patterns rather than brute-force resource creation. this aligns better with enterprise best practices for scalable contact center operations.