Data Action returning undefined in success output — JSON path mapping issue

Architect & Flows
1

Why does this setting return undefined despite a valid 200 response? I’ve verified the payload structure matches the schema. The Data Action executes, but the success output variable is empty. I’ve tried adjusting the JSON path from $.data to just $, but it remains null. The external endpoint is live. Here is the mapping config:

{
 "outputField": "customer_id",
 "path": "$.result.id"
}

Any ideas?

2

I think the js sdk for architect data actions is strict about json path syntax and null handling. you are likely hitting a case where the response body is not a json object but a raw string or the path points to a non-existent key. the sdk uses a standard json path library that fails silently on type mismatches. check the raw response in the logs. if the endpoint returns application/json, ensure the content-type header is set. if it returns text/plain, the sdk cannot parse $.result.id. try mapping to just $ first to see the full payload. if that works, drill down. also, verify the external service is not returning a 204 or empty body. here is a debug snippet using the sdk to validate the path locally before deploying to architect.

import { PureCloudPlatformClientV2 } from '@genesyscloud/purecloud-platform-client-v2';
import { JsonPath } from 'jsonpath-plus';

const client = new PureCloudPlatformClientV2();
// simulate the response
const res = await client.apiClient.request('/your/endpoint');
const body = JSON.parse(res.body);

// test the path
const result = JsonPath.query(body, '$.result.id');
console.log('path result:', result);
if (result.length === 0) {
 console.error('path failed. check structure:', body);
}

this isolates the issue from the architect runtime.

3

Check your Content-Type header. The suggestion above is correct. If the endpoint returns text/plain, the JSON path parser fails silently.

  1. Force application/json in the response headers.
  2. Verify the payload is a valid object.

Missing content-type headers are a common trap in internal APIs.

4

You need to check the raw response body in the logs. docs state “the JSON path is evaluated against the parsed JSON body.” if the endpoint returns text/plain it fails silently. force application/json header.

5

The suggestion above is correct regarding the Content-Type header, but you must also verify how the Data Action parses the response body before applying the JSON path. If your external service returns a JSON array instead of an object, or if the response is wrapped in an envelope, the path $.result.id will fail silently.

Here is how to debug and fix this in Genesys Cloud Architect:

  1. Inspect the Raw Response: Enable Debug Mode on the Data Action. Check the Response Body in the execution logs. Ensure it is valid JSON.
  2. Verify JSON Path: Use an online JSON path tester with your actual response payload. If the response is { "data": { "result": { "id": "123" } } }, your path $.data.result.id is correct. If it is [ { "id": "123" } ], use $.data[0].id.
  3. Handle Null Values: Add a Condition after the Data Action to check if customer_id is empty. Route to a fallback if needed.

Example Data Action configuration:

{
 "name": "Fetch Customer",
 "method": "GET",
 "url": "https://api.example.com/customer/{{contact.phone}}",
 "headers": {
 "Accept": "application/json",
 "Authorization": "Bearer {{oauth_token}}"
 },
 "outputFields": [
 {
 "name": "customer_id",
 "path": "$.data.result.id"
 }
 ]
}

If the endpoint returns text/plain, you must wrap the response in JSON at the source or use a Transform step to parse it. I recommend adding logging to your external API to confirm the exact payload structure. This often resolves undefined outputs in success scenarios.