Could someone explain the rate limiting behavior for the Workforce Engagement Management APIs when performing bulk agent status updates under high concurrency? I am currently designing a load test scenario to validate system stability during peak shift changes. The environment is US1. Using JMeter 5.6 with Genesys Cloud SDK 2.3.0. The test scenario involves simulating 500 concurrent agents changing their availability status from ‘Available’ to ‘Busy’ simultaneously. This mimics a large-scale break shift start. The flow uses the PUT /api/v2/wfm/schedules/agents/{agentId} endpoint to update availability. When the test reaches approximately 100 requests per second, I start seeing a significant increase in HTTP 429 Too Many Requests errors. The response headers indicate a retry-after value of 1 second. The test plan includes proper OAuth2 token refresh logic, so authentication is not the issue. The goal is to determine the maximum sustainable throughput for this specific API endpoint without triggering rate limits that could impact actual user experience. I have reviewed the documentation on API rate limits but found limited specific guidance on WEM endpoints under concurrent load. The current JMeter configuration uses a concurrent users thread group with a ramp-up period of 10 seconds. Each thread loops 10 times to simulate multiple status changes per agent. The error rate jumps from less than 1% to over 40% once the throughput exceeds 120 RPS. I need to understand if there is a hard limit per tenant or per API key for these operations. Additionally, I am unsure if the rate limiting is applied per endpoint or across all WEM APIs. Any insights on how to structure the load test to stay within acceptable limits while still validating capacity would be appreciated. I am also considering implementing exponential backoff in the JMeter script to handle the 429 errors gracefully. Does the SDK provide any built-in retry logic for rate-limited responses? I have not found a clear example in the documentation. The test results show that the API latency increases significantly when rate limiting kicks in, averaging 2 seconds per request compared to 200 milliseconds under normal load. This delay could cause issues in a real-world scenario where agents need immediate feedback on status changes. I am looking for best practices on how to model this concurrency in load tests to get accurate capacity planning data. The current approach seems to trigger limits too aggressively, making it hard to determine the true system capacity. I have tried reducing the concurrent users to 200, but the 429 errors still appear at lower throughput levels. This suggests that the rate limit might be stricter than expected or that there is a global limit being hit. Any clarification on the specific rate limits for the WEM availability update API would be helpful. I want to ensure the load test accurately reflects production constraints without artificially limiting the test scope.