Something strange is happening with a data action - it’s failing with a 400. The payload looks correct in Terraform, but the actual POST request being sent seems…off. It’s like there’s an encoding issue somewhere.
We’ve got a data action set up to POST to a custom endpoint - pretty simple stuff. It’s triggered from an Architect flow on after-call. The flow’s sending the {{call.id}} and {{caller.phoneNumber}} as parameters.
Here’s the Terraform for the data action:
resource "genesyscloud_dataaction" "example" {
name = "Post Call Data"
version = "1.0"
description = "Sends call data to custom endpoint"
method = "POST"
url = "https://example.com/api/v2/flows/actions/publish"
request_body = jsonencode({
call_id = "{{call.id}}"
caller_number = "{{caller.phoneNumber}}"
})
}
The API endpoint expects JSON. It’s not super fancy. When I look at the Genesys Cloud Data Action logs, this is what I see in the request payload:
Notice the \u007b\u007d bits? Those are escaped curly braces. It’s treating the template variables like strings instead of evaluating them. It looks like the jsonencode function is escaping the curly braces intended for variable interpolation.
We’re on Genesys Cloud, API version v2. Terraform provider is v3.66.0.
Is anyone else seen this? Is there a way to tell Terraform to not escape those braces? Or maybe a different way to build the request body that won’t cause this? We tried setting escape_special_characters = false but it didn’t make a difference.
Also - does anyone know if there’s a way to see the actual request that’s sent from the Data Action, like a raw HTTP log? The ones in the UI are not showing the full details.
Okay, so -1 to assuming Terraform is the source of truth here.
It’s probably the data action’s JSON payload construction. The Architect flow is concatenating strings, right? That’s where things get…messy. The {{call.id}} and {{caller.phoneNumber}} variables aren’t automatically JSON-encoded. They’re just plain text.
You need to explicitly stringify them. Something like this in your data action’s payload:
It seems obvious, but the Genesys Cloud platform doesn’t magically know you want valid JSON. It’s just sending whatever the flow gives it - literally. It’s a common mistake. It’ll probably solve the 400.
Sorry for the newbie question, my English is not perfect. That’s a really common mistake - assuming the data action’s input parameters are automatically formatted for JSON. It’s not. You’ll get 400s every time if you’re just passing plain text.
But - are you sure the issue isn’t the encoding of the data action itself? We had a similar problem last year when we rolled out the new agent gamification leaderboard. The data action was supposed to pull agent performance data, but it kept failing because the tenant had special characters in the data action name - like an apostrophe or a hyphen.
It sounds weird, but the API chokes on those. Try renaming the data action to something simple - no spaces, no symbols. Something like ‘postCallDataAction’. And then double-check the data action’s request body in the Architect flow. Is it actually sending what you expect? We had a consultant tell us Terraform was the problem, and it took us three days to find out the data action was misconfigured.
Also, is the custom endpoint expecting a specific content type? Sometimes it’s not just what you’re sending, but how you’re sending it. If the endpoint needs ‘application/json’ in the header, the data action won’t automatically add that. You have to specify it. I’ve never had to do that, but it might be worth checking.
Okay, so this is a really common issue - and sorry, I still get tripped up on the term “payload” versus “parameters” sometimes, it’s all a bit confusing - but I think we’ve seen similar things when we were integrating the client app with Architect. The earlier reply about stringifying the parameters is absolutely right, but you might also need to pay attention to the Content-Type header on the data action.
We found that even when the JSON looks correct, if the header isn’t set to application/json, the endpoint will often reject it with a 400. Terraform should be setting that, of course, but it’s worth double-checking in the Genesys Cloud UI itself. You can edit the data action and check the “Headers” section - make sure there’s a key-value pair of Content-Type: application/json.
Also, a quick thought - and I’m still really new to all this, so bear with me - are you encoding any special characters in the {{caller.phoneNumber}}? We had a weird issue where a plus sign (+) was being interpreted as something else. It’s a long shot, but it’s worth checking. You could try URL-encoding it on the Architect side, or escaping it in the data action payload. Here’s a snippet of how we do that in a React component we use for setting up the data action:
Fun one today. Think of the data action as a translator - it takes what Architect says and turns it into something the external endpoint understands. If Architect is speaking gibberish, the translator will fail, and you’ll get a 400.
The earlier replies are spot on - the variables aren’t automatically JSON encoded. We had a similar situation last month with a webhook that was expecting a structured payload. Turned out the Architect flow was just slapping strings together.
Here’s how to fix the payload construction. Instead of just passing {{call.id}} and {{caller.phoneNumber}}, wrap them in JSON.