The flow execution endpoint is rejecting my request with a 400 Bad Gateway, even though the JSON looks perfect. I’m trying to trigger a specific Architect flow from an external Node.js service. The documentation says executionConfig is optional, but omitting it doesn’t help. Here’s the payload I’m sending:
{
"flowId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"executionConfig": {
"queueName": "Support Queue"
},
"inputs": {
"callerNumber": "+2348000000000"
}
}
The response is just:
{"errorCode":"invalid.request","message":"Failed to parse request body."}
I’ve validated the JSON structure multiple times. It’s valid. The flow ID exists and is active. I’m using the standard Genesys Cloud JS SDK for the auth token generation, so that’s not the issue. The headers are set to application/json. I’ve tried removing the executionConfig block entirely, but get the same error. Is there a hidden schema requirement for the inputs object that isn’t documented? Or is this a known bug with the v2 flows endpoint?
Cause: You left inputs empty. The API expects valid JSON objects, not trailing commas or undefined fields.
Solution: Remove the empty object or provide actual key-value pairs.
{
"flowId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"executionConfig": {
"queueName": "Support Queue"
}
}
The point above is correct about the trailing comma being a syntax killer, but that’s rarely why this endpoint throws a 400 in production. The real issue is usually the executionConfig structure or missing required inputs for the specific flow you’re targeting.
If your flow expects inputs, leaving that object empty or omitting it entirely will cause the execution to fail validation before it even hits the routing logic. You need to map the inputs exactly as defined in the flow’s input schema.
Here’s a working curl example that actually triggers a flow with inputs. Note the strict JSON formatting and the explicit input mapping:
curl -X POST "https://api.myniceone.com/api/v2/flows/executions" \
-H "Authorization: Bearer <your_token>" \
-H "Content-Type: application/json" \
-d '{
"flowId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"executionConfig": {
"queueName": "Support Queue"
},
"inputs": {
"customer_id": "12345",
"issue_type": "billing"
}
}'
Also check your OAuth token scopes. The token needs flow:execute permission. If you’re using a user token, make sure the user has the “Execute Flows” capability enabled in their role. App tokens work fine too, but they need the right scope granted in the application configuration.
One more thing. If you’re calling this from a Studio script using the REST Proxy action, you don’t need to handle the token manually. Just set up the OAuth2 connection in the data source and map the JSON body directly. The proxy handles the auth header for you.
Double check the flow ID too. Sometimes people copy-paste the ID from the UI URL instead of the actual resource ID. They look similar but aren’t the same. The UI ID is a hash, the API needs the UUID. Easy mistake to make when you’re tired.
Check the response body in the 400 error. It usually tells you exactly which field failed validation.