Dealing with a very strange bug here with our custom adherence management widget built on the Genesys Cloud AppFoundry platform. We are attempting to programmatically update bulk adherence exceptions for a specific team of agents using the /api/v2/wfm/schedules/bulk/exceptions endpoint. The integration runs on a scheduled basis to sync exception data from our external HRIS system, utilizing a machine-to-machine OAuth token with the wfm:exception:update scope. The request payload adheres strictly to the schema defined in the Swagger documentation, including valid startDate, endDate, and reasonCode fields mapped to existing WFM entities. However, upon execution, the API returns a 409 Conflict error with the message Unable to update exception due to scheduling conflict or invalid state. This is particularly puzzling because the exact same payload succeeds when sent manually via Postman, and the target schedules are confirmed to be in a DRAFT or APPROVED state, not LOCKED. We have implemented exponential backoff and retry logic, but the conflict persists across multiple attempts within the same 15-minute window. The issue appears to be related to internal locking mechanisms or optimistic concurrency checks that are not clearly documented in the standard API reference. We are currently on the latest stable release of the Genesys Cloud APIs, and our AppFoundry widget is deployed in a multi-tenant environment with strict rate limit monitoring. The error response does not provide a specific conflictId or detailed reason beyond the generic message, making it difficult to pinpoint which specific exception item is triggering the rejection. We have verified that no other processes are modifying these schedules simultaneously, and the agent IDs in the payload are active and correctly associated with the target schedule group. Is there a known issue with bulk exception updates when using M2M tokens, or is there a specific header or parameter required to bypass this locking mechanism for programmatic updates?