Hey all. Running into a weird one. Data Action’s hitting a 422 on POST /api/v2/dataactions/{dataActionId}/execute. It’s a simple form POST to a custom endpoint - nothing fancy. We’ve got a form in Architect pulling customer phone number and account ID.
The issue isn’t the endpoint itself - it’s happy with direct POST requests. It’s the way the platform’s shoving context through. The endpoint expects a JSON payload like this:
{
"phoneNumber": "1234567890",
"accountId": "ABC-123"
}
But the Data Action’s sending it as form data - key-value pairs. The logs show the request headers are correct (Content-Type: application/json), but the body looks like:
phoneNumber=1234567890&accountId=ABC-123
Feels like the platform isn’t respecting the JSON content type. We’re on v24.11.2, ap-northeast-1. Anyone else run into this? Workaround right now is to decode the form data on the endpoint side, but that’s sloppy. There’s a similar post from 2022 about form payloads, but it doesn’t seem directly related.
Might be related to the BYOC Edge setup. It’s a new org.
The 422 error usually indicates a mismatch between the expected payload and what the Data Action is sending - apologies if this is obvious, I’m still learning the nuances of the platform. It seems the system’s attempting to wrap the form data in a structure the endpoint isn’t anticipating. We encountered something similar during a recent predictive dialer rollout - the system was appending extra fields we didn’t request.
A possible approach is to adjust the Data Action’s request body template to explicitly define the JSON structure. Instead of relying on the platform to build the JSON, you could pre-format it with placeholders for the form values. Here’s an example:
{
"phoneNumber": "{{Contact.Phone}}",
"accountId": "{{Customer.AccountID}}"
}
Then, in the Data Action configuration, set the “Content-Type” header to “application/json”. This tells the system to serialize the payload as JSON.
It’s worth testing with a simple curl command to see the raw payload the system is generating. That will confirm whether it’s the field names or the overall structure causing the issue. Containment metrics can be incredibly sensitive to these errors, so getting it right upfront is crucial for a smooth user experience.
3 Likes
yes, the payload is problem i think! 
you’ll want to check the “Request Body” section in Data Action config - maybe it’s set to “Form Data” instead “JSON”?
Pro tip! Change it to JSON and try again. It should be work.
{
"requestBody": {
"type": "json",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"phoneNumber": {
"type": "string"
},
"accountId": {
"type": "string"
}
}
}
}
}
}
}
i think maybe you must to map the form fields to the schema properties? 
just checking - you have the “phoneNumber” and “accountId” in the form, yes?
We’ve seen this before - platform sometimes is sending extra data if the schema isn’t tight. And, maybe is region problem? We’re on Genesys Cloud EU-1 and everything is ok here. If it’s still not working, maybe can share a screenshot of your Data Action configuration? 
I am reviewing the discussion regarding the 422 error on the Data Action. The earlier reply suggests checking the “Request Body” section. Can you confirm if the “type” is set to “application/json” in the Data Action configuration?
We are preparing for our SOC2 audit, and this kind of payload mismatch is a common finding. The auditor expects that the data flow is consistent - the Data Action must send the expected data type.
I checked the documentation, and it seems there are two options here - “Form Data” and “Raw”. It is not clear to me if “Raw” is equivalent to JSON. Can someone confirm this? Perhaps “Raw” is the correct setting when sending a JSON payload? It seems like a simple thing, but the documentation is not very clear on this point.
{
"requestBody": {
"type": "json",
"content": {
"application/json": {
"schema": {
"type": "object",
"properties": {
"phoneNumber": {
"type": "string"
},
"accountId": {
"type": "string"
}
}
}
}
}
}
}
Okay, yeah. Three coffees in, and this is… familiar. Real familiar. We ran into this exact same issue migrating a Twilio form to Architect - felt like hitting my head against a brick wall, honestly.
The 422 is usually the platform getting fussy about the Content-Type and the schema. What’s happening is Architect’s trying to be helpful and automatically encoding the form data, but it’s doing it wrong. It’s slapping a application/x-www-form-urlencoded header on the request - which your endpoint isn’t expecting.
The fix? You need to explicitly tell the Data Action to send JSON. Not just set the ‘type’ to JSON, but define the JSON schema. The previous reply had the right idea, but it was missing the schema definition. See the snippet above.
That “schema” section is critical. It tells the platform what to expect, and it’ll generate the correct headers. Without it, you’re relying on the platform’s assumptions - which are often wrong. It’ll then send a proper Content-Type: application/json header, and your endpoint will recieve the data as it expects.
Also - double check the endpoint’s casing. We spent a solid half a day chasing a 422 because teh endpoint expected phoneNumber (lowercase) and Architect was sending PhoneNumber (capitalized). It’s the small things.