Security Policy API 429s during high-concurrency load test ramp-up

Administration
1

I’m trying to figure out why the Security Policy endpoints are throttling so aggressively during our automated load tests. We are running JMeter 5.6.2 from our Singapore lab against a BYOC Edge environment (version 24.2) to validate platform stability under stress. The test scenario involves simulating bulk administrative actions, specifically updating security policies for multiple organizations concurrently.

The target endpoint is PUT /api/v2/security/policies/{policyId}. The test plan uses 50 concurrent threads with a 5-second ramp-up period. Each thread executes the update request once. We are using valid OAuth2 tokens generated via the standard client credentials flow. All requests include the correct Authorization: Bearer header and Content-Type: application/json.

Error Message:

The 429 errors start appearing almost immediately after the ramp-up completes, affecting about 80% of the requests. The Retry-After header is consistently set to 1 second. We have verified that the tokens are not expired and that the policies exist. The issue is reproducible across multiple test runs.

We are aware of the general API rate limits documented in the Genesys Cloud developer portal, but the threshold seems significantly lower for security-related endpoints compared to analytics or messaging APIs. For context, similar concurrency levels on POST /api/v2/communications/messages did not trigger 429s.

Is there a specific rate limit configuration for the Security Policy API that we need to request an increase for? Or is this behavior expected for high-concurrency updates to security resources? We need to ensure our automation scripts can handle bulk policy updates without manual intervention.

Environment Details:

  • Genesys Cloud BYOC Edge 24.2
  • Region: Asia/Pacific Southeast
  • Tool: JMeter 5.6.2
  • Concurrent Threads: 50
  • Endpoint: PUT /api/v2/security/policies/{policyId}

Any insights or workarounds would be appreciated. We are trying to determine if this is a hard limit or if there is a configuration we are missing.

HTTP/1.1 429 Too Many Requests
Retry-After: 1
X-Request-Id: a1b2c3d4-e5f6-7890-abcd-ef1234567890