How does the POST /api/v2/wfm/schedules/bulk endpoint actually handle burst requests before throttling kicks in? Ran a methodical test pushing 120 schedule blocks per second against v12.1.0 in the Tokyo org and the admin UI claims everything’s green while the backend drops packets at exactly 65 concurrent calls, returning 429 Too Many Requests with zero retry headers. Sorry for the basic question, still figuring out the WFM module since the official docs don’t mention burst caps, but the response payload just cuts off mid-JSON:
{"error_code": "rate_limit_exceeded", "message": "..."
Retry logic won’t trigger a backoff and the sync is doing jack all.