Why is this setting causing a 400 Bad Request when launching an Architect flow via the REST API from my Java orchestration service? I am attempting to trigger a specific flow execution programmatically to handle a bulk data sync event from MuleSoft. The flow ID is confirmed active, and the user context I am passing has the necessary flow:execute scope. However, the Genesys Cloud API consistently rejects the request with a 400 status code, citing a generic validation error in the response body.
I have constructed the HTTP POST request using the standard OkHttp client library in Java. The endpoint is https://{myorg}.mygen.com/api/v2/flows/executions. The request headers include Content-Type: application/json and a valid OAuth2 Bearer token. The JSON payload is structured according to the official documentation for the FlowExecutionRequest object. Here is the exact payload I am sending:
{
"flowId": "a1b2c3d4-5678-90ab-cdef-1234567890ab",
"user": {
"id": "usr-9876-5432-10fe-dcba"
},
"customData": {
"batchId": "sync-2023-10-27",
"sourceSystem": "mulesoft-erp"
}
}
I have verified the flowId by fetching it via GET /api/v2/flows/{id}, which returns successfully. I have also confirmed that the user.id exists and is active. I even tried removing the customData field to see if that was causing a schema mismatch, but the 400 error persists. The error message from Genesys Cloud is unhelpful, simply stating: Invalid request body. Please check the payload structure.
I am using Java 17 and the latest Genesys Cloud Platform SDK for Java. I have also tried constructing the request manually without the SDK to rule out any library-specific serialization issues. The behavior is identical. Is there a specific hidden requirement for the FlowExecutionRequest that is not documented? Or could this be related to how the flow is configured to accept external triggers? I need to understand exactly which field or configuration is triggering this validation failure so I can adjust my Java service accordingly.
What is causing the 400 Bad Request on POST /api/v2/flows/executions when the JSON payload appears structurally valid and all referenced IDs exist?