DATA ACTION POST - 400 Bad Request

Right - another day, another DATA ACTION headache. We’re hitting a 400 Bad Request on POSTs to our endpoint, and the error message is spectacularly unhelpful - “Invalid character encoding.” It’s happening on about 1 in 50 calls, completely random.

The flow is simple enough. Architect flow has a TRANSFER action, then a DATA ACTION. DATA ACTION URL is https://our-endpoint.com - standard stuff. We’re passing a JSON payload with customer details - name, account number, the usual.

The weird thing is the payload looks fine when we log it on our side. The request headers are all set up correctly - Content-Type: application/json, Accept: application/json. Been staring at the logs for hours.

We’re using the Java SDK, version 3.2.1. Tried encoding the payload as UTF-8 explicitly before sending - didn’t fix it. Checked the endpoint logs, and the request body is often garbled - looks like some characters are getting escaped twice or something. Not consistently, mind you.

Here’s an example of the request body we’re sending - the one that sometimes works, sometimes doesn’t:

{
 "accountNumber": "1234567890",
 "customerName": "John Doe",
 "interactionId": "some-unique-id"
}

I’ve tried Base64 encoding the payload before POSTing, as a complete shot in the dark - that just made it throw a different 400 error. The endpoint itself is working perfectly when called directly with Postman.

Anyone else run into this? Honestly, at this point, I just need a workaround - a way to reliably get the data through. Thinking of adding a retry mechanism in Architect, but that feels like masking a real issue. We’ve got a DUCTION queue stalled because of this. The API documentation is useless, naturally.

{
 "payload": {
 "contentType": "application/json",
 "body": {
 "customerDetails": {
 "name": "{{Contact.FirstName}} {{Contact.LastName}}",
 "accountNumber": "{{Account.AccountNumber}}"
 }
 }
 }
}

That “Invalid character encoding” error almost always means the Data Action isn’t receiving perly escaped JSON. We’ve seen this a bunch of times - especially with the Genesys Cloud for Salesforce package - and the solution is to explicitly set the Content-Type header to application/json and ensure your payload is a valid JSON string. Check your Apex class; it’s easy to forget the per escaping for the values coming from the Contact and Account objects. Someone had a similar issue last month in the Architect forum, and they were passing unescaped ampersands.