Anyone know why the Set Variable action in Genesys Cloud Architect is rejecting the JSON payload returned from a ServiceNow REST API call?
The integration uses a Data Action to trigger an incident creation in ServiceNow via POST /api/now/table/incident. The response includes the sys_id and number fields. When mapping the response body to a local variable using the JSON path $.result.sys_id, the flow consistently fails with an “Invalid JSON path” error during runtime.
The ServiceNow endpoint returns a standard 200 OK with the expected structure. Verified the payload using Postman and the Genesys Cloud Data Action test tool. The issue appears isolated to the Architect flow execution context.
The Data Action logs show a successful execution with HTTP 200, but the subsequent Set Variable step cannot parse the response. This suggests a potential issue with how Genesys Cloud handles nested JSON objects in webhook responses within the Architect environment.
Check your JSON path syntax within the Set Variable configuration. The ServiceNow response structure often wraps the actual data in a result object, but the path might need adjustment if the payload varies. Try using $.result.sys_id explicitly and verify the raw response in the Conversation Detail view to ensure the structure matches expectations.
Yep, this is a known issue when integrating ServiceNow with Genesys Cloud via the platform API. The root cause often lies in how the response payload is structured versus what the Set Variable action expects. While the suggestion above to check the JSON path is correct, the real culprit is usually the content-type header or the specific version of the ServiceNow API being called. If you are using the older REST API, the response might be wrapped differently than the modern Table API. Ensure your Data Action is explicitly setting the Accept header to application/json. Additionally, verify that the response body isn’t being truncated due to size limits in the flow execution context. A common fix is to add a Debug action immediately after the Data Action to log the raw response body. This confirms whether the sys_id is actually present in the $.result object or if it is nested deeper. If the path is correct but still failing, try using the JSON Extractor action instead of Set Variable for more robust parsing capabilities.
TL;DR: Check the raw payload.
You might want to look at the actual response body in the debug logs. ServiceNow often nests data differently than expected, so verify the exact JSON structure before trusting the path syntax.