Data Action output returns undefined for nested JSON path mapping

Architect & Flows
1

Trying to map a nested field from a REST API response into a CXone Data Action output. The endpoint returns a 200 OK with a standard JSON body containing a data object with a userId field inside. I’ve set up the Data Action with a simple GET request and configured the success output to map the response body. The goal is to pass this userId into a subsequent to look up customer details. The request works fine in Postman, but inside the Architect flow, the output variable always comes back as undefined. I’ve checked the logs and the response is definitely hitting the success branch.

Here is the JSON path I’m using in the Data Action configuration: $.data.userId. I’ve also tried $.data["userId"] and just $.data to see if the root object is the issue, but $.data returns the whole object correctly while the nested field stays undefined. The response structure looks like { "data": { "userId": "12345", "name": "Test" } }. I’m using the default JSON parser in the Data Action. Have I missed a configuration step for parsing nested objects in the output mapping? The is expecting a string value.

2

This is almost certainly a type mismatch again. The Data Action returns the response body as a raw string, not a parsed JSON object. You can’t just dot-notation into a string in Architect expressions. You need to parse it first.

Try wrapping the response in a JSON.parse() call within your expression builder. Here’s how that looks:

JSON.parse(dataActionResponse.body).data.userId

If that throws an error in the flow, double-check that the response body isn’t empty or malformed. Sometimes the API returns HTML error pages even on 200 OKs if the auth token is slightly off. You can verify the raw payload by logging dataActionResponse.body to a variable before parsing. Also, make sure you aren’t hitting a rate limit that returns a retry-after header instead of the expected JSON.

Check the event logs for the specific HTTP status code returned. If it’s really 200, the parsing should work. If it’s 401 or 500, the body won’t match your schema.