Trying to understand how to properly invoke a shared flow from multiple inbound call flows without duplicating the logic. i’m building a central validation module that checks caller ID against a block list and updates a custom attribute. currently i have three distinct inbound flows hitting this same validation logic. copying the 20+ steps into each flow is painful and a maintenance nightmare when the block list logic changes.
i read in the docs that you can use GetRESTProxy to call an internal endpoint. the documentation states “you can invoke a flow via the REST API using the /api/v2/flows/execute endpoint”. so i tried setting up a snippet action with GetRESTProxy pointing to https://myinstance.niceincontact.com/api/v2/flows/execute. i passed the flow_id of my common module in the body.
the request fails with a 400 Bad Request. the error message is just {"message": "Invalid flow execution request"}. i’ve checked the auth token in the header and it’s valid. am i missing a required parameter in the JSON payload for the flow execution? or is this endpoint restricted for internal flow calls?
is there a better way to do this or am i messing up the payload structure? how do i successfully call a shared flow from another flow using the REST API in Studio?
Check your GetRESTProxy config. you’re likely hitting the spec mismatch again. the generator strips x-internal tags for Studio snippets, so your client sees a 404. force the endpoint into paths with operationId: studio.snippet.execute. here’s the patch:
If I remember correctly, that GetRESTProxy hack is messy and breaks every time the internal API schema shifts. you’re overcomplicating this. you don’t need REST calls for shared logic in Architect. just use the Subflow pattern. it’s been there forever and it’s meant exactly for this.
create one flow dedicated to validation. name it something clear like Global_CallValidation. inside that flow, put your block list check and attribute updates. make sure the flow has a clear entry point and exit. no triggers needed on the subflow itself.
then, in your three inbound flows, add a Run Subflow block. point it to that validation flow. pass the caller ID as an input parameter if you need it inside the logic, though usually you can just access call.callingNumber directly.
here’s how the block list check looks inside the subflow using a simple API call to your data source:
// Example logic inside a Script block in the Subflow
const blockList = await platformClient.DataManagementApi.getDataDocumentByName("BlockList");
const caller = session.get("call.callingNumber");
if (blockList.value.includes(caller)) {
session.set("isBlocked", true);
throw new Error("Blocked Caller"); // Or route to a busy tone
} else {
session.set("isBlocked", false);
session.set("validatedAt", new Date().toISOString());
}
this keeps your main flows clean. when the block list logic changes, you update one file. not three. the GetRESTProxy approach adds latency and requires managing scopes and error handling for a simple internal jump. don’t do that.
if you’re hitting issues with variable passing, ensure the subflow inputs match the parameters you’re sending. sometimes the studio cache lags, so refresh the flow list in the designer.
i’m in Mexico City time right now, so if you need a hand debugging the subflow config, ping me later today. but really, just use subflows. it’s the standard for a reason.