Trying to understand the rate limiting behavior for the Workforce Management Schedule API when pushing bulk updates via JMeter. We are currently validating the platform’s capacity to handle high-concurrency schedule imports for a large agent population. The goal is to simulate a scenario where multiple supervisors are updating schedules simultaneously during a peak shift-change window.
We are using JMeter 5.6.2 with a Thread Group configured for 500 concurrent users. Each thread is sending a POST request to /api/v2/wfm/schedules/{scheduleId}/assignments. The payload contains a batch of assignment updates for roughly 20 agents per request. We have implemented a constant throughput timer to maintain a steady load, but we are hitting a hard wall at around 150 requests per second. Beyond this threshold, the API starts returning HTTP 429 Too Many Requests errors consistently. The response headers indicate a Retry-After value of 5 seconds, which is significantly impacting our test execution time and preventing us from reaching the target concurrency of 1000 updates per minute.
The error response body is generic, just stating “Rate limit exceeded”. We have checked the documentation for standard API rate limits, but there is no specific mention of WFM Schedule API limits under high concurrency. We are also seeing occasional 503 Service Unavailable errors mixed in with the 429s, which suggests the backend might be struggling with the load rather than just enforcing a soft limit.
Is there a specific rate limit for the WFM Schedule API that we are missing? Should we be batching these requests differently or using a different endpoint for bulk operations? We are looking for the optimal way to structure these requests to avoid hitting the rate limits while still achieving high throughput. Any insights into the internal queuing mechanism for WFM APIs would also be helpful.