WFM Bulk Schedule Update 502 on Edge Nodes During Peak Load

Just noticed that our premium app is experiencing intermittent 502 Bad Gateway errors when executing bulk schedule updates via the Workforce Management API. The issue appears consistently during high-concurrency windows, specifically when pushing schedule data to multiple partner organizations simultaneously. We are utilizing the multi-org OAuth flow to authenticate requests, which seems stable, but the downstream WFM service calls are failing. The endpoint in question is /api/v2/wfm/schedules/updates, and we are sending payloads containing approximately 500-750 schedule entries per request. The error response body is minimal, typically returning just Bad Gateway without detailed error codes from the Genesys platform layer. This suggests the issue might be at the edge node level or a timeout between the edge and the WFM backend services. We have verified that the request headers, including X-Genesys-Application-Id and Authorization, are correctly formatted and that the tokens have not expired. The latency spikes correlate with the error occurrences, with response times jumping from the usual 200-300ms to over 10 seconds before the 502 is returned. We have checked the WFM API Rate Limits documentation and confirmed that we are well below the stated thresholds for our partner tier. However, the behavior suggests a potential resource exhaustion issue on the edge nodes processing these large bulk operations. Are there known limitations on payload size or concurrent requests for bulk schedule updates? We are considering implementing exponential backoff and smaller batch sizes, but we want to confirm if this is a known platform issue or if our implementation needs adjustment. Any insights into debugging 502 errors specifically related to WFM bulk operations would be appreciated. We are operating in the America/Los_Angeles timezone, and the issue has been observed across multiple edge regions.