Getting a 400 Bad Request on POST /api/v2/architect/flows when trying to reference a shared module. The JSON payload for the trigger looks fine, but the integration node fails validation. Here is the node config causing the error:
{
“id”: “shared-ref-01”,
“type”: “integration”,
“action”: “callSharedFlow”,
“parameters”: {
“flowId”: “a1b2c3d4-e5f6-7890-abcd-ef1234567890”
}
}
Does the integration node support direct shared flow invocation or do I need to wrap it in a subflow first?
You’re missing the version context in that node config. The API doesn’t just take a flow ID; it needs to know which version of the shared flow you’re calling. If you leave it out, the validator throws a 400 because it can’t resolve the dependency. It’s a pretty common gotcha when moving from the GUI to raw JSON.
Here’s how the parameters block actually needs to look. You’ll need to grab the version number from the shared flow definition itself. Usually, it’s 1 for the first publish, but if you’ve updated it, bump that number up.
{
"id": "shared-ref-01",
"type": "integration",
"action": "callSharedFlow",
"parameters": {
"flowId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"version": 2
}
}
If you’re managing this via Terraform, you can pull the version dynamically from the genesyscloud_flow data source or resource. Hardcoding versions is a nightmare for drift, so I always use the genesyscloud_flow resource attribute. Something like genesyscloud_flow.my_shared_flow.version.
Also, double-check that the shared flow is actually published. Draft versions won’t resolve in an inbound flow trigger. The API is strict about that. If the flow is in draft, you’ll get the same 400.
One more thing. Make sure the inbound flow and the shared flow are in the same organization context. Cross-org calls require a different setup entirely, usually involving the API gateway or a webhook, not a direct callSharedFlow action. If they’re in the same org, the version fix should clear the validation error. Just update the JSON payload and retry the POST.