Problem
The admin UI locks the Data Action Configuration timeout at 3 seconds. We know the external system handles requests fine, but the response consistently clocks in at 4.8 to 5.2 seconds. The Gateway Configuration just drops the call with a timeout error before the payload even makes it back. You can’t just drag a slider in the UI to fix it, so we’re hitting the flows API directly to patch the node. The whole setup feels clunky when the downstream service runs a bit slower than expected.
Code
Here’s the JSON payload we’re pushing to the update endpoint:
{
"id": "d4a7b2c1-88f0-4e3a-9b2c-112233445566",
"type": "dataAction",
"configuration": {
"name": "FetchExternalInventory",
"timeout": 5000,
"url": "https://inventory.internal/api/v1/check",
"method": "POST",
"headers": {
"Authorization": "Bearer {{auth.token}}"
}
}
}
We’re using the Python SDK to call platform_client.flows.update_flow. The request goes through without a 400, and the UI actually reflects the change for a few seconds before snapping back to the default 3000ms. Weird behavior.
Error
The runtime log just spits out DataActionTimeoutException: Execution exceeded the maximum allowed duration. No 4xx or 5xx from the external endpoint. The Routing Profile handles the fallback fine, but we’re losing the inventory data every single time. You’d think the Platform SDK would just accept the integer, but the backend validation seems to be enforcing a hard cap on the Timeout Setting.
Question
Is there a hidden parameter in the flows update endpoint that actually overrides the cap? We’ve tried passing {"timeout": 6000} in the nested configuration object, and we’ve even tried adding a custom property to the Flow Configuration. Nothing sticks. The admin UI clearly enforces the limit, but maybe there’s a flag in the request headers or a specific scope we’re missing. Anyone got a working snippet that actually pushes a higher timeout through without the system reverting it? We’re just trying to get the Data Action Configuration to play nice with a slightly slower downstream service. The logs keep showing the 3000ms cutoff…