Could someone explain the interaction between Architect flow execution timeouts and platform API rate limits? We are deploying a Premium App that queries external data via a Data Action within a high-volume IVR. The flow hangs at the 30-second mark, but our logs show 429s from the Genesys side, not the third-party vendor. Is the Architect engine enforcing a hard stop before the retry logic in our custom integration can complete?
{
"retryDelayMs": 5000,
"maxRetries": 3,
"timeoutMs": 10000
}
The 30-second Architect timeout is a hard constraint for the flow execution path, not just a soft suggestion. When the Data Action hits the platform API, it triggers internal rate limiting (429) before the external call completes. The engine kills the transaction to protect the media server resources.
[WARN] FlowExecution: Timeout exceeded after 30000ms. Status: 429 Too Many Requests.
To fix this, add an exponential backoff in your custom integration code. Do not rely on the Architect retry block alone, as it resets the entire flow timer. Instead, handle the 429 locally with a small delay (5-10 seconds) and reduce the concurrent thread count in your JMeter script. The platform API rate limits for Data Actions are strict. If you are simulating high concurrency, you must throttle the requests to stay under the per-org limit. This prevents the cascade failure where the flow times out before the retry logic can even trigger.