Data Masking API 403 during JMeter burst test on US1

I’ve spent hours trying to figure out why the Data Masking configuration endpoint returns 403 Forbidden when JMeter threads exceed 30 concurrent users. The environment is Genesys Cloud US1. We are running a load test to validate the security compliance settings under high concurrency. The goal is to ensure that the API can handle simultaneous updates to PII masking rules without dropping connections or returning authentication errors. The test script uses valid OAuth tokens obtained via the standard client credentials flow. Each thread performs a PUT request to the /api/v2/wf/crm/masking endpoint. The payload includes standard JSON configuration for SSN and credit card masking. When the thread count is below 30, the requests succeed with 200 OK. Once the count reaches 31, the server immediately responds with 403 Forbidden. The error message body contains “Permission denied for resource update”. This behavior is consistent across multiple test runs. The OAuth tokens are valid and have the necessary scope for admin_config. The user account associated with the token has full administrative privileges. The issue does not appear to be related to token expiration, as the test duration is short and tokens are refreshed if needed. It seems like there is a hidden rate limit or a concurrency check specific to security configuration endpoints. The standard API documentation mentions general rate limits but does not specify restrictions for data masking endpoints during burst scenarios. We need to understand if this is a platform limitation for security endpoints or a misconfiguration in our test setup. Any insights into how Genesys Cloud handles concurrent writes to security settings would be helpful. We are trying to determine the safe upper limit for configuration updates during peak load periods. The current result prevents us from validating the system’s resilience to simultaneous admin actions.