Agent Scripting API returning 400 Bad Request when injecting dynamic variables into WFM Schedule Context

So I’m seeing a very odd bug with the Agent Scripting API when trying to push dynamic schedule context variables to the WFM module via a custom Architect flow. We are using the v2 scripting engine and have a flow that triggers on agent login to fetch their specific shift details from our internal HRIS via a REST API lookup. The flow then attempts to update the agent’s scripting context using the PUT /api/v2/wfm/scheduling/agents/{agentId}/context endpoint. The issue is that when the payload includes nested JSON objects for shift preferences, specifically the ‘swapAvailability’ array, the API consistently returns a 400 Bad Request with the error code ‘INVALID_PAYLOAD_STRUCTURE’. The documentation states that the context payload should be a flat key-value map, but our integration team believes we need nested structures to handle complex shift swap rules. I have verified the JSON structure using the Swagger UI test console, and it validates correctly there, but fails in production. The error response body provides little detail, just a generic message about malformed input. We are running this in the US-EAST-1 region, and the agent IDs are correct UUIDs. I suspect the issue might be related to how the scripting engine serializes the nested object before sending it to the WFM service. Has anyone successfully passed complex objects through the scripting context to WFM? If so, what is the correct serialization format? We need this to work for our weekly schedule publishing process to ensure agents see their correct swap options. The current workaround involves flattening the JSON, but that breaks our downstream logic in the agent desktop widget. Any insights on the expected payload structure or known limitations with nested objects in the scripting context would be greatly appreciated. We are on the latest platform version, and this started happening after the last quarterly update. I have checked the release notes, but nothing specific mentions changes to the WFM context API. I am open to alternative approaches if the current method is deprecated.