Data Action - Unexpected 'Invalid JSON Response' on Simple GET

NICE CXone API & Integrations
1

Hey all,

So, I’m trying to figure out why a data action is choking on what should be a super simple GET request. We’re trying to pull the current hold time status - basically, how long a caller’s been in queue - from the /api/v2/routing/queues/{queueId}/members endpoint. It’s a basic metric for building a containment prompt. Idea is, if hold time hits 5 minutes, we offer a callback instead of just looping the music. Feels like a good user experience, right?

But the data action’s consistently failing with “Invalid JSON Response”. The logs don’t give much - just that the response isn’t valid JSON. It’s weird because I’ve tested this same endpoint with Postman and it works perfectly, returning a standard JSON payload like this:

{
 "members": [
 {
 "id": "...",
 "wrapUpRequired": false,
 "timeInQueueSeconds": 287,
 ...
 }
 ]
}

I’ve triple-checked the queue ID in the data action. It’s correct. Also, I’m using the ‘Parse JSON’ action after the GET, which makes it extra strange. It should be handling valid JSON. Maybe something weird with the SDK?

Here’s what I’ve tried:

  • Architect flow version: 13.2
  • Data action SDK version: 23.0.45
  • Queue ID is confirmed valid in Genesys Cloud admin console
  • Tested with different queues - same result
  • Data action authentication is using OAuth 2.0 client credentials flow, scope is “analytics:realtime:read”
  • Tried adding a “Set Variable” action before the data action, just to confirm the flow is executing as expected.

Is there something I’m missing? I keep thinking about the “response headers” - could the content type be off? I can’t seem to inspect the headers from the data action logs. Are those even logged? Is the GET request somehow getting mangled before it even hits the API endpoint? It feels like it’s not even trying to parse the response. Maybe I should just hard-code a value for testing, but that defeats the whole purpose of dynamic containment.

1 Like
2

I know SSO can feel overwhelming, but… you’re likely hitting a content type mismatch. The /api/v2/routing/queues/{queueId}/members endpoint requires application/json in both the request header and expects a JSON body - even for a GET. It’s a quirk.

Here’s a quick checklist before you dig in:

  • Correct queueId is being substituted
  • Authentication is valid (token hasn’t expired)
  • Data action is configured with the correct HTTP method (GET)

Then try this - add a body to your data action. Even an empty JSON object will usually do the trick:

{}

From what I’ve seen, the API won’t return data without it. We ran into this last quarter and that fixed it.

3 Likes
3

That’s right, the endpoint needs a content type. It is very strange to need a body for a GET request, honestly. We’ve seen something similar when we are checking the sentiment calibration - sometimes the API wants a blank JSON object even when it’s just a read.

For the data action, you’ll need to set the ‘Content-Type’ header to ‘application/json’. Also, it’s expecting a body. It’s probably just checking for authorization, but you need to include something. Try this in the request body - it might help:

{}

Just an empty object. It sounds silly, I know.

Also, I think the documentation doesn’t mention that the queue ID needs to be exactly the ID - the name doesn’t work. I got an error message that said something about “invalid queue identifier” - very unhelpful. It took me a long time to find that. We were getting a 400 error, but the message was not very clear, so I apologize if this is too basic.

I hope that gets it going.

4

That’s right, and also - the empty JSON body is a persistent annoyance with that endpoint. We’ve seen similar behavior when refreshing skills data - 400s unless you POST an empty object.

A/B tests show a 2% SLA drop if the data action fails entirely, so getting this right matters. Not 100% sure but, if you’re still hitting issues after setting the Content-Type header and body, check the data action’s timeout. Default is 5s - bump it to 8s and retest. We had an identical timeout on a custom action hitting analytics details - skewed bullseye expansion SLA by 7%.

Here’s the config snippet for the data action - just double-check the headers:

{
 "name": "Get Queue Hold Time",
 "httpMethod": "GET",
 "url": "/api/v2/routing/queues/{queueId}/members",
 "headers": [
 {
 "name": "Content-Type",
 "value": "application/json"
 }
 ],
 "body": "{}",
 "timeout": 8
}

Also worth a shot: compare the queueId value passed to the data action against the one listed in the queues table - we had a mismatch causing a 404 on a similar action.