WFM Schedule API 422 Validation Errors for Custom Attributes in Multi-Org App

Need some troubleshooting help with a specific validation issue we are encountering with the Workforce Management Schedule API. Our AppFoundry integration is designed to sync external roster data into Genesys Cloud. We are currently pushing schedule entries via POST /api/v2/wfm/schedules/entries. The payload includes standard fields like user_id and shift details, along with a set of custom attributes defined in the WFM configuration. The environment is a multi-org setup, and the OAuth token used has the wfm:admin scope. The request succeeds for standard attributes. However, when we include the custom attribute named ‘shift_type_external’, the API returns a 422 Unprocessable Entity error. The error message is generic: ‘Invalid input provided.’ It does not specify which field is causing the failure. We have verified the attribute definition in the WFM UI. The data type is set to string. The value being passed is ‘night_shift’. We have tested this with multiple users across different organizations. The error persists regardless of the user or org. We are using the latest version of the Genesys Cloud SDK for Python. The issue seems isolated to this specific custom attribute. Other custom attributes work fine. We have checked the attribute key for case sensitivity. The key matches exactly what is defined in the system. We are unsure if there is a hidden validation rule for certain attribute names. Or if the multi-org context is affecting the attribute resolution. The integration needs to push thousands of records per hour. This error causes the batch job to fail partially. We need a reliable way to identify the exact cause of the 422 error. The standard error response lacks the detail needed for debugging. Is there a debug flag or a more verbose error response available for WFM APIs? We have contacted support, but they suggested checking the attribute definition again. We have done that multiple times. Any insights from other developers building WFM integrations would be appreciated. We are looking for a workaround or a fix.