Data Action JSON Parse Error when calling Cognigy Profile API

Running into a wall with a Data Action trying to fetch user profile data from NICE Cognigy. The setup is straightforward. I have a Genesys Cloud user attribute cognigy_profile_id that I pass to the Cognigy API. The endpoint returns valid JSON, but the Data Action consistently fails with a JSON_PARSE_ERROR on the response body.

• Source: Genesys Cloud Architect Data Action
• Target: https://api.nice.com/cognigy/v1/profiles/{id}
• Auth: Bearer token passed in header
• Response Content-Type: application/json
• Payload Structure: Standard nested object with attributes array

The curl from my local machine (Lagos timezone, late night debugging) works fine. The response looks clean. Here is the raw JSON coming back from Cognigy:

{
 "id": "p_12345",
 "name": "Test User",
 "attributes": [
 {
 "key": "loyalty_tier",
 "value": "gold"
 }
 ]
}

In the Data Action, I mapped the response to a JSON variable. The error log just says Failed to parse response as JSON. I’ve checked for BOM characters, trailing commas, nothing. Is Genesys Cloud’s internal JSON parser stricter than standard? Or is there a specific Content-Type header quirk I’m missing in the outbound request config? The request headers are set to Accept: application/json.

The Genesys Cloud Data Action documentation explicitly states: “The response body must be a valid JSON object or array. If the response is a JSON string, it must be parsed before assignment.”

You’re likely hitting the case where Cognigy returns a JSON string inside the body, or the headers are misleading the parser. The .NET SDK handles this gracefully with JsonConvert.DeserializeObject, but the Architect Data Action is stricter. It doesn’t auto-parse stringified JSON.

Check the raw response in the Architect trace. If you see "{\"id\": \"123\"}" instead of {"id": "123"}, that’s your problem. The outer quotes make it a string to the parser, not an object.

Here’s how I handle this in my Azure Functions when bridging GC to external APIs. You can’t fix it in the Data Action if the source is stringified, so you have to fix it upstream or use a Scripting node (JS) to strip it.

If you control the endpoint, ensure the Content-Type is application/json and the body is raw JSON. If you can’t change Cognigy’s output, use a JavaScript node in Architect before the Data Action to parse it:

// Architect JavaScript Node
const input = event.data.cognigy_response_body; // assuming this is the stringified JSON
let parsedData;
try {
 parsedData = JSON.parse(input);
 event.data.cognigy_profile = parsedData;
} catch (e) {
 event.data.error = "Failed to parse Cognigy response";
}

Then point the Data Action to event.data.cognigy_profile instead of the raw HTTP response. The docs warn about this: “Ensure the response is a parseable JSON structure. String-encoded JSON will fail.”

Also, check if Cognigy is returning UTF-8 BOM. That breaks JSON parsers too. If you’re using .NET to proxy this, use StreamReader with Encoding.UTF8 and DetectEncoding to be safe.

// .NET Proxy Example
var client = new HttpClient();
var response = await client.GetAsync(cognigyUrl);
var content = await response.Content.ReadAsStringAsync();

// Trim BOM if present
if (content.StartsWith("\ufeff"))
{
 content = content.Substring(1);
}

// Return clean JSON
return new ContentResult { Content = content, ContentType = "application/json" };

The Data Action is just a HTTP client with a parser. It doesn’t do heavy lifting. If the JSON is weird, it fails. Keep it clean.