Architect Data Action: External REST JSON Mapping to Variables

Architect & Flows
1

Struggling to figure out why my Data Action fails to map the nested JSON response from our external scheduling API to Architect variables. The HTTP 200 OK is returned, but the variables remain null. My mapping JSON uses response.body.data.schedule as the source. Is the syntax incorrect for accessing array indices in the response body? Here is the relevant Mapping Configuration snippet. Any ideas on why the extraction fails?

1 Like
2

Verify the JSON structure first. Architect paths do not auto-index arrays.

  • Check if data.schedule is an array.
  • Use response.body.data.schedule[0].startTime for the first item.
  • Ensure variable types match the payload (String vs Number).
"startTime": "response.body.data.schedule[0].startTime"
1 Like
3

Make sure you validate your custom integration timeout settings before deploying. The suggestion above regarding array indexing is correct for the path syntax, but it ignores the backend failure mode common in data actions. If response.body.data.schedule is large or the external API has latency spikes, the Data Action execution might timeout before the full JSON is parsed into the context, resulting in null variables despite a 200 OK header from the remote service. I see this often in Asia/Seoul deployments where cross-region calls to US-East APIs exceed the default 30s limit.

First, check the timeout property in your Custom Integration configuration. If it is not explicitly set, it defaults to a value that might be too short for complex payloads. Second, verify the Content-Type header. Architect expects application/json. If your external API returns text/plain or omits the header, the parser might fail silently.

Here is the corrected Custom Integration JSON snippet with explicit timeout and header validation:

{
 "name": "ExternalScheduler",
 "endpoint": "https://api.example.com/schedule",
 "method": "POST",
 "headers": {
 "Content-Type": "application/json"
 },
 "timeout": 60,
 "responseMapping": {
 "startTime": "response.body.data.schedule[0].startTime",
 "endTime": "response.body.data.schedule[0].endTime"
 }
}

If the variable remains null, add a debug step in Architect to log response.body as a string. This reveals if the payload is actually empty due to a timeout or if the JSON structure differs from your expectation. Do not rely on the HTTP status alone; inspect the raw body in the error logs.

4

don’t trust the 200 OK. if the external endpoint hangs, architect kills the thread and leaves variables null. check dialog_timeout on the action node.

1 Like
5

the timeout theory is spot on. i’ve seen this exact behavior where the remote api takes 12 seconds to respond and architect defaults to 10. you get a 200 from the network layer but the data action fails silently. check your dialog_timeout setting. also, make sure you’re not hitting the max payload size. if the json is huge, it might get truncated.

increase the timeout to 20 seconds just to be safe. here is how you set it in the data action config:

{
 "name": "FetchSchedule",
 "type": "REST",
 "url": "https://api.example.com/schedule",
 "dialog_timeout": 20000,
 "mapping": {
 "startTime": "response.body.data.schedule[0].startTime"
 }
}

if that doesn’t fix it, enable debug logging on the flow and look for DATA_ACTION_TIMEOUT. it’s usually a config issue, not a code issue.

1 Like