WFM API 409 Conflict on Bulk Shift Swap Approval in Genesys Cloud 2024.5

Struggling to figure out why the bulk approval endpoint for shift swaps is returning a 409 Conflict error with the message ‘Resource state inconsistent’ when processing requests for agents in the America/Chicago timezone. We are running Genesys Cloud version 2024.5 in the US-East-1 region and this issue has started occurring consistently during our weekly publishing cycle on Friday afternoons. The specific API call failing is POST /api/v2/wfm/schedules/shiftswaps/approve. We are sending a batch of approximately 150 shift swap requests that have already been approved by the receiving agents and meet all coverage thresholds defined in our WFM rules. The payload includes valid user IDs, swap start/end timestamps in ISO 8601 format, and the correct schedule ID. However, the response body indicates a conflict on three specific agents who are part of a shared skill group. Interestingly, these same agents do not have any overlapping time-off requests or existing schedule conflicts visible in the UI. We have verified that the schedule has not been published yet and that the agents’ availability windows are correctly configured. The error occurs specifically when the swap involves a shift that crosses the midnight boundary in Chicago time, suggesting a potential issue with date parsing or timezone handling in the backend validation logic. We have attempted to isolate the issue by submitting single swap requests for these agents, which succeed without error, indicating the problem is related to the batch processing logic or a race condition when multiple swaps for the same skill group are processed simultaneously. Our internal logs show no corresponding errors in the Architect flows that trigger the approval, ruling out a downstream integration failure. We need to understand if this is a known limitation of the bulk approval endpoint or if there is a specific configuration in the WFM rules engine that is causing these transient conflicts. Any insights into the internal validation steps that lead to this 409 error would be greatly appreciated as we are currently forced to approve swaps individually, which is impacting our team’s efficiency during peak planning hours.