How do you actually pass dynamic parameters to an Architect flow when hitting POST /api/v2/flows/executions from a backend script? Dropped this payload into the request body and it keeps flagging the complianceFlag reference as invalid. The docs mention a request body but my curl test just returns a 400 Bad Request since it’s rejecting the parameters field. Schema looks off somewhere.
curl -X POST https://mycompany.mygen.com/api/v2/flows/executions
-H “Authorization: Bearer $TOKEN”
-H “Content-Type: application/json”
-d ‘{“flowId”: “a1b2c3d4-e5f6-7890-abcd-ef1234567890”, “parameters”: [{“name”: “complianceFlag”, “value”: “true”}]}’
-
Check your JSON structure first. The API expects a specific format for the parameters object, not just a loose map. If you’re sending {"complianceFlag": true}, it might be failing if the flow expects a string or a specific type.
-
Here’s a working curl example that usually clears up the 400 errors:
curl -X POST "https://mycompany.mygen.com/api/v2/flows/executions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
-d '{
"flowId": "YOUR_FLOW_ID",
"parameters": {
"complianceFlag": "true"
}
}'
-
Make sure complianceFlag matches the exact name defined in the Architect flow’s input parameters. Case sensitivity matters here.
-
If you’re using the Genesys Cloud Terraform provider, you can also test the flow execution via genesyscloud_flow data source to validate the parameter schema before hitting the API directly. This helps catch drift between your code and the actual flow definition.
Yeah, nailed the type mismatch issue, but there’s another gotcha that trips people up constantly. The parameters object inside the request body doesn’t just take raw values. It needs to be wrapped in a specific structure if you’re passing data that the flow expects to parse as a JSON string or if you’re dealing with complex objects.
Also, make sure your Architect flow actually has a “Request Body” trigger configured. If you’re hitting the endpoint but the flow isn’t expecting a request body, Genesys Cloud will just ignore the parameters or throw a 400 because the schema validation fails on the trigger side.
Here’s what the payload should look like. Note the value wrapper for the parameter. This is crucial if the flow definition expects a string representation of the data.
{
"parameters": {
"complianceFlag": {
"value": "true"
},
"customerName": {
"value": "John Doe"
}
}
}
If your flow is set to expect a JSON object in the request body trigger, you might need to pass the whole thing as a stringified JSON in the value field, depending on how the data source is mapped in Architect. It’s annoying, but that’s how the API bridges the gap between the HTTP request and the flow data context.
Check the flow trigger settings. If it’s set to “None” for request body, you won’t get these parameters regardless of how perfect your JSON is.