User Data Action failing - 400 Bad Request

General Discussion
1

{"code":"bad-request","message":"Failed to parse request body: Missing required property 'queryType'","details":[{"field":"queryType","message":"Missing required property"}]}

This is happening on a data action we’re using to pull user details in an Architect flow - specifically, the ‘Get User’ action. It was working fine last week. The API endpoint it’s hitting is /api/v2/users/{userId}.

We’re building the URL within the data action script, and the userId is passed in dynamically from the interaction. I checked the payload being sent, and it seems fine - the userId is resolving correctly. Saw a similar issue a while back in the community, someone mentioned checking the data action’s expected response format - that didn’t help. The script is Node.js, latest version available in the platform. It’s not a permissions issue, the user account associated with the data action has the necessary roles.

2

That error’s… interesting, isn’t it? The /users endpoint doesn’t require queryType - it expects userId as a path parameter, and any query parameters should be added to the URL string itself. Option A - double-check that your Data Action’s URL construction isn’t accidentally adding queryType as a top-level property in the request body instead of a query string parameter - that’s where we’ve seen similar hiccups!!

Option B - if the URL looks right, try explicitly setting queryType to an empty string in the body - sometimes the platform gets finicky about missing properties, even if they aren’t documented as required. It’s a workaround, sure, but it’s faster than chasing ghosts in the API sometimes.

1 Like
3

That fix worked - we were passing queryType as a JSON body property instead of a URL parameter. Should’ve caught that. It was a copy-paste error when refactoring the script last week.

4

That’s right - it’s easy to miss where parameters go. We’ve seen this too, especially when moving scripts between environments.

If you’re building the URL entirely inside the data action script, you can sometimes run into issues with escaping. It’s cleaner to construct the full URL using Terraform and pass the complete URL to the data action as a parameter.

Here’s an example of how we do it - it avoids a lot of string manipulation inside the script itself.

resource "genesyscloud_dataaction" "example" {
 name = "get-user-details"
 action_type = "http"
 url = "https://api.mypurecloud.com/api/v2/analytics/users/details/query"
 http_method = "POST"
}

Then, in your Architect flow, you just pass the genesyscloud_dataaction.example.id to the ‘Get User’ action.

Are you using variables for the queryType too? Sometimes the variable substitution isn’t happening correctly and the script sends the variable name itself instead of the value. You can check the execution logs in Genesys Cloud to confirm the exact request being sent. That helps a lot.

2 Likes
5

  • that’s right, passing it as a body property instead of a query parameter is a classic. the earlier post’s point about Terraform is good too - we’ve been pushing more of the URL construction into infrastructure-as-code lately. makes rollbacks a lot easier.

  • small thing - but have you checked what happens if the userId is empty? the API usually throws a pretty standard error, but it’s worth testing. we ran into a case where a flow was accidentally passing a blank userId, and it was failing with a different message - took forever to track down.

  • long story short - we had a similar issue a while back. what helped us was using CloudFormation to deploy the Data Action with the URL already baked in as a parameter. Here’s a snippet:

Resources:
 MyDataAction:
 Type: 'GenesysCloud::DataAction'
 Properties:
 Name: 'Get User Details'
 ActionType: 'HTTP'
 Url: !Sub 'https://api.mypurecloud.com/api/v2/users/${userIdParameter}'
 Method: 'GET'
 Parameters:
 - Name: 'userIdParameter'
 DataType: 'String'
  • a question - are you using any kind of request transformation within the Data Action script itself? sometimes those can introduce unexpected changes to the request. just curious if that could be part of it.
1 Like