So I’m seeing a very odd bug with the JSON payload handling in a multi-step Architect flow. The Data Action node fails intermittently with a parse exception when the upstream HTTP response contains nested arrays.
Error: 400 Bad Request - Invalid JSON structure at index 124
The flow version is 14.2 and the issue persists across multiple queue configurations. Is there a known limitation on payload depth for these actions?
As far as I remember, the 400 Bad Request error in Architect Data Actions is rarely about JSON depth limits and almost always stems from how ServiceNow REST APIs handle nested arrays within the payload structure. The Genesys Cloud Data Action node expects a flat or strictly hierarchical JSON object, but many ServiceNow table APIs, particularly for Incident or Task records, require specific formatting for multi-value fields or child records. When the upstream HTTP response contains nested arrays that do not align with the expected ServiceNow schema, the parser throws an index error. To resolve this, you need to explicitly map the nested data in the Architect flow before passing it to the ServiceNow Data Action. Use the ‘Map’ node to flatten the array into a single JSON string or an object that matches the ServiceNow API requirements. For example, if you are sending a list of attachments, ensure the payload looks like {"attachments": [{"filename": "doc.pdf", "content": "base64string"}]} rather than an array of raw strings. Additionally, check the ServiceNow REST Message configuration to ensure it is set to handle JSON content types correctly and that the ‘Content-Type’ header is explicitly set to application/json. I have seen this issue persist when the Data Action does not have the correct input schema defined, causing the parser to fail on unexpected array structures. Try adding a ‘Transform’ node to validate and format the JSON payload before it hits the ServiceNow endpoint. This usually eliminates the intermittent parse exceptions.