Data Action - Metric POST failing

{"error":"invalid_request_body","message":"Request body is not a valid JSON object.","code":"400","details":[{"field":"body","message":"Invalid JSON: Unexpected character at line 1, column 1"}]}

Okay, this is… annoying, isn’t it? We’re seeing intermittent 400 Bad Requests on a Data Action POST to our custom endpoint - DogStatsD, specifically. It’s not constant, maybe one in ten requests fails, which makes debugging a nightmare. The flow is pretty straightforward - interaction ends, Data Action fires, POSTs a few metrics. We’re on Genesys Cloud with the latest Architect version, and the Data Action SDK is v2.11.0.

The endpoint expects simple key-value pairs - metric name and value as a float. The Data Action is configured to send JSON, of course. But the error suggests the JSON is completely invalid. Which, well, doesn’t make sense. I checked the logs before the Data Action fires, and the data being passed is valid JSON.

So, what’s going on? Option A - the Data Action wrapper is double-encoding the JSON. It’s happened before, it’s a sneaky one!! The wrapper adds another layer of JSON encoding, and if the original JSON isn’t perfectly formatted, it breaks. Worth a shot to manually string-format the POST body instead of relying on the JSON formatting in the Data Action configuration. It’s more work, but avoids potential encoding problems.

Option B - the interaction attributes themselves are getting corrupted somewhere. It’s unlikely, but possible. We could add a logging step immediately before the Data Action to print the interaction attributes to the interaction timeline, just to confirm they are what we expect. This is a bit messy, and adds overhead.

Option C - the endpoint is intermittently having issues. We can check the endpoint’s logs, but it’s been stable for other integrations. It’s the least likely, but something to rule out.

I’ve tried adding a simple JSON.stringify() in a script block before the Data Action, thinking it might fix the encoding. Didn’t change anything. The weird part is, the successful calls look exactly the same in the logs as the failed ones. It’s like a race condition or something equally awful.

Here’s the relevant part of the Data Action config:

{
 "url": "https://dogstatsd.example.com/metrics",
 "method": "POST",
 "headers": {
 "Content-Type": "application/json"
 },
 "body": "{ \"metric\": \"{{interaction.custom.metricName}}\", \"value\": {{interaction.custom.metricValue}} }"
}

It’s baffling, honestly. The metricName and metricValue are simple strings and floats, pulled directly from interaction attributes. I’m leaning towards the double-encoding issue.

That error’s usually a serialization issue- the Data Action is sending something that isn’t valid JSON to your endpoint, even if it looks right in the flow designer- we’ve seen it before with complex objects. Try adding a “String Concatenate” node before the Data Action, explicitly serializing the payload to JSON using this expression: {{Serialize($.interaction.customData)}}. It forces the platform to handle the conversion, and that’s often enough to resolve it.

1 Like

That Serialize() trick As noted above is good stuff - we’ve seen similar quirks with complex customData payloads. Also, double-check the Content-Type header in the Data Action - it absolutely has to be application/json, or the endpoint will choke even on valid JSON. It’s a small thing, but the platform sometimes forgets to set it correctly.

{
 "interactionId": "{{$.interaction.id}}",
 "customData": "{{Serialize($.interaction.customData)}}"
}

That serialization suggestion is… a workaround for a fundamentally BROKEN API. It should just handle the JSON, but fine. Wrap the entire payload in a JSON object, explicitly passing the interaction ID too - it’s required, apparently. Worth a shot.

1 Like