Hi UiPath Community,
What is the recommended approach in UiPath to handle REST API timeout issues?
Should we use retry mechanisms, HTTP timeout settings, or a combination of both? Also, what would be the best way to handle temporary API failures in a production automation?
Any best practices would be appreciated. Thanks!
I would just throw a retry around the HTTP call, assuming you don’t care too much about speed.
As for the greater process, try building your process around a queue. Then when items fail due to system outages, the queue item can be retried and processed again.
Hi @Mayur001 ,
For REST API timeouts in UiPath, I’d recommend using a combination of proper timeout settings and retries. The HTTP Request activity supports retrying failed requests. For temporary failures, retry only a limited number of times, add a short delay between attempts, and log the response/error. If it still fails, handle it through Try Catch and raise a controlled exception.
Thanks
Hiii @Mayur001
I think using a combination of timeout settings and retries would be a good approach.
First, set the HTTP timeout based on the expected API response time. For temporary issues like timeouts or 5xx errors, you can then use a retry mechanism with a reasonable retry count and delay between attempts.
For production, I would also recommend logging the status code and error details and retrying only transient errors. Errors such as 400, 401, or 403 generally need to be handled differently rather than retried.
This approach can make the automation more reliable while avoiding unnecessary API calls.
Hope this helps! 
Hi @Mayur001,
Set an explicit timeout on the HTTP Request activity, and use its built-in retry policy (2 to 3 attempts with exponential backoff) for timeouts.
In production, throw a System Exception once retries are exhausted so REFramework or queue retries can pick the item up later. Check for duplicates before retrying POST or PUT calls, and log the status code and response with alerts on repeated failures.
Cheers!
I would recommend to use retry mechanisms for 3 to 4 times, if still getting errors then raised an system exception.
One thing I’d add: retry safety depends on the verb. GET retries are fine but blindly retrying POST/PUT on a timeout is risky - you don’t know if the original call actually succeeded before it timed out so you risk duplicates (as @Prashanth_D mentioned).
Hi @Mayur001,
Welcome to the community.
It depends on the type of API operation, such as creating, retrieving, updating, or deleting a record.
In many cases, the issue can be caused by a timeout, so you can increase the HTTP timeout based on the API’s expected response time.
For create/update operations, you should be careful with retries. Before retrying, check whether the record was already created or updated. Most of the time, you may get an error response, but the change can still take some time to be reflected in the data source.
If the API supports duplicate handling, you can retry safely; otherwise, check the existing record first to avoid duplicate data.
Make sure you log the API response/error and retry attempts so the failure can be investigated if all retries fail.
Thanks!
Welcome to the community
as of now the best approach would be to use the new http request activity which has in built retry mechanism and you can choose what can be retried and how long to wait before the retry
cheers
cheers