Getting empty variables when mapping a nested array from an external REST API in a Data Action. The API returns a JSON object with a list of items. I’m trying to map the first item’s ID to an Architect variable using the path $.data[0].id. The test connection works, but the mapping returns null at runtime. Here is the sample response payload I’m seeing. Is the syntax for array indexing correct in the JSONPath mapper, or do I need to flatten this first? json { "data": [ { "id": "12345", "name": "test" } ] }
I ran into this exact same issue last week when pulling data from our CRM integration. The $.data[0].id syntax is technically correct for standard JSONPath, but Architect’s Data Action mapper can be a bit picky about how it handles arrays coming from external REST sources, especially if the response isn’t strictly typed.
What I found was that the mapper often fails to resolve the index [0] if the array is empty or if the response structure shifts slightly at runtime. Instead of trying to grab the first element directly in the path, I switched to using the first() function provided by the JSONPath library Architect uses. It’s much more resilient.
Try changing your path to:
$.data.first().id
If that still comes back null, you might need to verify the actual structure of the response in the Data Action logs. Sometimes the API wraps the array in an extra layer that doesn’t show up in the “Test Connection” preview. You can dump the whole payload to a variable to inspect it:
$.data
Then check the variable content in the flow log. If the array is there, the first() method should definitely pick it up. It saved me a lot of head-scratching when dealing with inconsistent REST responses.
The JSONPath syntax $.data[0].id is technically correct, but Architect’s mapper is notoriously strict about null checks. If the array is empty, the whole path fails. As noted above the strict typing issue, but there’s a simpler workaround using the ? operator for safe navigation.
Try changing the path to $.data[?(@.id)]. This filters for items that actually have an id field. If you only need the first one, you might still hit the index issue. A more reliable pattern in C# integrations is to flatten the response before sending it to Architect.
Here’s how I handle it in an Azure Function that acts as a proxy. Instead of returning the raw array, I map it to a single object if it exists:
public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
{
var client = new HttpClient();
var response = await client.GetAsync("https://api.external.com/data");
var content = await response.Content.ReadAsStringAsync();
var json = JObject.Parse(content);
var dataArray = json["data"] as JArray;
// Return null if empty, otherwise the first item
var result = dataArray?.Any() == true ? dataArray[0] : null;
return new OkObjectResult(result);
}
Then in Architect, just map $.id directly. No array indexing needed. The docs for Data Actions state that “complex nested structures may require preprocessing,” which is code for “don’t make Architect parse arrays.”
Also, check the Content-Type header. If the external API returns application/json; charset=utf-8 but Architect expects plain application/json, it might reject the payload silently. I’ve seen that break mappings without any error log. Add a header transform in the Data Action to force application/json.