We are building a custom integration where our Architect flow needs to pull user context from NICE CXone via Cognigy profile tokens. The goal is simple: get the token, pass it to a Data Action, parse the JSON, and map the fields for a downstream API call.
The issue is that the Data Action keeps failing with a generic 400 error, but only when the payload contains certain unicode characters or specific nesting structures from the Cognigy token. If I hardcode a simple JSON object, it works fine. When I inject the actual token string retrieved via a previous GET request, it breaks.
Here is the JSON payload structure coming back from the Cognigy API:
{
"token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c",
"user_data": {
"language": "en-US",
"preferences": {
"notifications": true,
"theme": "dark"
}
}
}
In the Architect Data Action, I am trying to map the user_data object. The error log in the Architect trace just says “Invalid JSON” or “Parsing error”. I have verified the token string itself is valid by running it through an external JSON validator. It seems like the Data Action parser is choking on the way the token is embedded or perhaps the escaping.
I am using the standard JSON parse function provided in the Data Action mappings. Is there a known limit or character set restriction when parsing large base64-encoded strings inside a JSON object in Architect? Or do I need to strip the token before passing it to the next action?
I have tried wrapping the value in double quotes and escaping the internal quotes manually in the mapping expression, but that seems to break the structure further. The logs don’t give much detail beyond the 400 status.
Any ideas on how to debug the specific character causing the parse failure?