PATCH /api/v2/wfm/schedules/{scheduleId} returns 409 Conflict when updating agent availability windows

Just noticed that our automated script, which runs every Sunday night to prepare the upcoming week’s schedule, is failing with a 409 Conflict response. This is happening specifically when we attempt to PATCH the schedule to adjust availability windows for agents who have pending shift swap requests.

The environment is running the latest Genesys Cloud release. We are using the Python SDK version 1.18.0. The error payload indicates that the schedule is in a publishing state, but we have verified via the UI that the previous week’s schedule is fully published and the new draft is in a draft state. The specific endpoint failing is PATCH /api/v2/wfm/schedules/{scheduleId}. The body of the request includes the updated agentAvailability array with new time blocks reflecting the approved swaps.

We have checked the RBAC permissions for the service account used by the script, and it has wfm:schedule:write and wfm:schedule:publish permissions. The issue seems to be related to the internal locking mechanism or a race condition with the shift swap approval workflow. When an agent approves a swap via the self-service portal, does the system hold a lock on the schedule object until the next publish cycle? Or is there a specific sequence of API calls required to release these locks before modifying the draft?

We are based in Chicago, so our weekly publish happens at 6 PM CST on Sundays. The script runs at 5:55 PM CST to ensure everything is ready. Recently, we increased the volume of shift swaps allowed during the week, and this error started appearing consistently. It feels like the system is treating the draft as if it is still being actively edited by another process, even though no other users are logged into the WFM module.

Has anyone encountered this specific conflict when updating schedules with active shift swaps? Is there a way to force a lock release or should we be querying the schedule status more granularly before attempting the PATCH? Any insights on how to handle these conflicts programmatically would be greatly appreciated, as manual intervention is slowing down our weekly workflow significantly.