Data Action returns 500 when parsing Cognigy Profile Token JSON

Architect & Flows
1

Running into a wall with a Data Action that queries NICE Cognigy. We’re trying to fetch a profile token and parse the response inside Architect. The HTTP call works fine in Postman, returns 200 OK with valid JSON. But in the Data Action, it’s throwing a 500 Internal Server Error on the parsing step.

The response from Cognigy looks like this:

{
 "status": "success",
 "data": {
 "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
 "expires_in": 3600
 }
}

The Data Action is configured with a JSON parser. I’ve mapped the output field to $.data.token. Standard dot notation. Nothing fancy. The error log just says “Invalid JSON” or “Parsing failed”. No specifics.

Tried a few things:

  • Verified the raw response in the Architect logs. It’s definitely valid JSON. No BOM, no extra whitespace.
  • Tried using a simple string parser action first. Same error.
  • Checked if the token contains any weird characters. It’s base64, should be safe.
  • Tested with a static JSON string in the parser. Works fine. So the parser itself isn’t broken.

The issue seems to be specifically when the Data Action tries to parse the dynamic response from the Cognigy endpoint. Is there a known issue with parsing nested JSON objects in Data Actions? Or maybe something with how the HTTP action passes the payload to the parser?

The endpoint is a custom integration. Using GET. Headers are set correctly. Authorization is handled via the integration config.

Anyone seen this before? What’s the trick to getting the parser to accept the response? Feeling stuck here.

2

You’re likely hitting the default JSON parser limits in Architect. Cognigy tokens can get pretty long, and the standard parseJSON step has a character cap that trips up on large payloads. It’s not a bug, just a configuration constraint.

Try switching to a JavaScript step instead. It gives you more control over how the payload is handled and bypasses the strict schema validation that’s causing the 500 error. Here’s a pattern that works for parsing nested tokens:

try {
 // Assume the raw response is in variable 'cognigyResponse'
 const parsed = JSON.parse(cognigyResponse);
 
 if (parsed.status === 'success') {
 // Extract the token safely
 context.set('profileToken', parsed.data.token);
 context.set('exp', parsed.data.expiry);
 flow.set('tokenValid', true);
 } else {
 context.set('errorMsg', parsed.message || 'Unknown error');
 flow.set('tokenValid', false);
 }
} catch (e) {
 // Catch invalid JSON specifically
 context.set('parseError', e.message);
 flow.set('tokenValid', false);
}

Make sure you’re passing the raw string body into the JS step, not the already parsed object. Architect sometimes pre-parses HTTP responses, which can cause JSON.parse to fail if it receives an object instead of a string. Check the variable type in the debugger.

If the token is still too large, you might need to chunk it or base64 encode it before passing it around, but usually the JS step handles it fine. Watch out for timeout issues if the Cognigy endpoint is slow, though a 500 on parsing is definitely a format or length issue.