43
Views
8
Comments
Solved
Best practice for handling REST API timeouts in OutSystems

Hi everyone, I am integrating an external REST API into my OutSystems application. Sometimes the API takes too long to respond. What is the best practice to handle timeouts gracefully in a Server Action? Should I use an Exception Handler or adjust the timeout settings in Service Studio?Looking forward to your suggestions!

2020-05-07 18-53-00
Rui Barradas
 
MVP
Solution

Hello Mina,

Hope you're doing well.

This is actually a very interesting question.

Before jumping into the details, you should ask yourself some questions:

  • If you increase the timeout, is it going to affect the overall performance of your application?
  • Is this timeout increase going to block user action on your app?
  • Is the API taking too long to respond regularly or occasionally?
  • Is the API changeable?


There are some suggestions that you can consider. For example, if the API takes too long to reply only occasionally, you may consider to not increase the timeout and implement a retry mechanism. I implemented this solution in the past and it worked like a charm. The API took longer to reply just occasionally because of parallel calls and load.

Another suggestion would be running this integration in an asynchronous process (Timer) and then notify the user.

A more advanced solution, considering that the API is changeable, would be consider to call the API, then it replies right after. But in the background, the API does the work and calls a webhook on your side to notify when the processing is done.


Long story short, there is not a "guideline" that you can blindly follow, it really depends on your use case. But replying directly to your question, I would adjust timeout to a reasonable value, always implement an Exception Handler and consider an async approach if these delays are common.


Kind regards,

Rui Barradas

2026-05-06 22-32-21
Mina Philip

Thank you Rui 

2024-10-05 13-30-20
Huy Hoang The

Hi @Mina Philip,

U must add handle exception to handle timeout and u also set increase timeout. Consider the need to increase the timeout because the default value may already be reasonable, and we need to respond to messages that match user experience. If it's too long, you should consider running it in the background (event).

Hope this helps!

2026-05-06 22-32-21
Mina Philip

Thank you Huy 

2026-03-05 14-21-52
José Pinto

Hello Philip

In practical terms you may use the timeout in seconds property from the REST API method


Or...as a way of fine tunning you can use a forge component like this one

https://www.outsystems.com/forge/component-overview/10349/rest-timeout-o11


Because it is .net code you need to place it on the OnBeforeRequestAdvanced of your consumed REST method (specify the timetout in milliseconds).

The .net code basically gets the current request and sets its timeout, it is very straightforward, you can use integration studio to check it out .

Regards
JP

2026-05-06 22-32-21
Mina Philip

Thank you José 

2018-12-10 12-16-21
Goncalo Duarte Almeida

Hi @Mina Philip 

In OutSystems, the answer isn't really an "either/or"—it’s a "both." You want to prevent the system from waiting forever while also ensuring your app doesn't crash when the clock runs out.

Here is one approach to handling REST timeouts:

Before you can handle a timeout, you need to define what "too long" actually means for your specific use case.

Set this to a reasonable limit (e.g., 10–20 seconds). If it’s a UI-blocking call, aim lower. If it’s a background sync, you can be more generous.

You should never call a REST API directly from a Screen Action. Instead, wrap the API call inside a Server Action. This allows you to centralize the logic and error handling.

If the API is consistently slow and the data isn't needed "live," consider moving the integration to a Timer and storing the result in a local entity.

Regards

2026-05-06 22-32-21
Mina Philip

Thank you Goncalo 

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.