Can anyone clarify the rate-limiting thresholds for the /api/v2/wfm/scheduling/shifts endpoint when bulk importing shifts derived from carrier availability reports? We are integrating real-time BYOC trunk status into our workforce planning logic. The integration polls trunk health every 5 minutes and pushes availability updates to WFM via the Data Action framework. During peak APAC morning hours, the system triggers a 429 Too Many Requests error after approximately 120 concurrent requests. The response headers indicate a retry-after of 10 seconds, but our queue backs up significantly. We suspect the issue stems from the high frequency of updates caused by carrier failover events in the Singapore region. Is there a recommended batching strategy or a higher-tier limit available for WFM shift operations? The current implementation uses standard OAuth2 tokens with the wfm:schedule:write scope. Logs show the requests are valid JSON payloads matching the schema. We need to ensure shift availability reflects actual trunk capacity without hitting API limits.