WFM Bulk Schedule Upload Hitting 429 Then 400 on Staging

Schedule sync jobs are timing out right after the initial handshake, throwing a 429 Too Many Requests even though the queue is completely empty. Pushed the wfm bulk upload connector to client staging org using genesys-cloud-sdk-js@3.91.2. The /api/v2/wfm/userschedule/bulk endpoint doing jack all. Request headers show the OAuth token’s valid for another twenty minutes, and the scope list includes wfm:schedule:write. Console logs keep repeating the rate limit hit at exactly 120 calls per minute, which matches the documented threshold for this tier. Payload structure matches the official schema, but it’s returning a blank error object with just a retry-after header.

Retrying the same batch with a sixty-second delay fixes the immediate block, yet the job still fails halfway through with a 400 Bad Request on the third segment. Architect flow on the partner side routes everything through a single premium app instance, so session persistence might be carrying over stale tokens. Checking the multi-org tenant config shows the correct routing key, but the SDK client doesn’t pool connections correctly. Network trace shows the keep-alive flags staying active across separate org contexts.

The WFM bulk endpoint isn’t a simple list, it expects a specific nested structure for the schedules array. Check your payload against the ScheduleRequest model in the SDK docs because a malformed body triggers that 400 immediately after the rate limit check.