I am currently consuming REST APIs that use JWT token-based authentication.
To handle authentication, The token is cached for 5 minutes; however, the API-issued token is only valid for 2 minutes. Due to this mismatch, I am encountering timeout and authentication-related errors, including failures during token generation in some scenarios.
To improve the reliability and resiliency of the integration, I would like to implement a centralized solution that includes:
1] Automatic token refresh when the existing token expires.
2] Retry mechanism with up to 3 attempts for transient failures.
3] Circuit Breaker pattern to prevent repeated calls to unavailable services and improve system stability.
Centralized exception handling and logging for all REST API integrations. Additionally, some API endpoints are invoked directly through button click actions, and I would like the same retry, token refresh, and exception handling mechanisms to be applied consistently across those scenarios as well.
In summary, I am looking to design and implement a centralized integration framework that handles authentication, token refresh, retries, circuit breaking, exception management, and logging for all outbound REST API calls in a maintainable and reusable manner.
Hi @Pradip Chavhan ,See this post for information -https://www.outsystems.com/forums/discussion/106786/api-failure-message-in-exception-handling/#Post469981This post is related to ODC platform implimention same you can apply in O11 or Traditional.
Automatic Refresh Token Handling
For automatic token refresh, you can maintain the token and its expiration date/time in a dedicated entity.
Recommended Approach
I would not recommend automatically refreshing the token inside every business API call. Token generation/refresh is part of the authentication mechanism and should ideally be handled separately.
A cleaner approach is:
API Request-Validate Token-Token Valid?├── Yes → Process Business Logic│└── No → Call Generate Token API↓Get New Token↓Update Token Store↓Process Business Logic
This keeps the authentication/token lifecycle separate from the business logic and makes the API flow easier to maintain and troubleshoot.RegardsRahul
Hi Rahul, Thank you for your valuable and detailed implementation guidance. I have one additional question. In scenarios where an exception occurs during the token generation process itself, what would be the recommended approach to handle it effectively? Specifically, I would like to understand the best practices for managing token generation failures within a centralized framework, including retry logic, exception handling, logging, and recovery mechanisms to ensure the application remains resilient and reliable. Thank you for your guidance.
In this scenario, I would suggest creating a generic response structure with attributes such as IsSuccess, ErrorCode, ErrorMessage, and the required response data.
If the GenerateToken action fails, return the appropriate error code and error message along with IsSuccess = False. Based on this response, the consumer can handle the failure and retry the token-generation request when required.
I have implemented a similar approach in one of my projects. In addition to the response handling, we capture the failures in Error Log, Sync Log, and Audit Log, which provides the team with complete visibility for monitoring and troubleshooting.
Hi Rahul,
Thank you for the detailed implementation guidance. Based on your suggestions, I believe I am currently on the right track.
I would appreciate your recommendation on whether it is appropriate to implement Retry Logic and the Circuit Breaker Pattern whenever an exception occurs, or if these patterns should be applied only to specific types of failures.
I have two distinct scenarios:
Dashboard API: A GET API that retrieves historical data for display on the dashboard.
Save Operation API: A POST API that is triggered when a user clicks a button to save data.
From a user experience perspective, I do not want users to experience excessive waiting times on the UI. I believe a maximum response time of approximately 5 seconds would be acceptable.
For the POST API, my current understanding is that implementing automatic retries may not be advisable due to the risk of duplicate transactions or data inconsistencies.
Instead, I am considering simply logging the exception and presenting an appropriate error message to the user.
Given these scenarios, I would appreciate your guidance on the following:
Would implementing a Circuit Breaker Pattern be beneficial for both GET and POST APIs?How would you recommend handling transient exceptions for data retrieval (GET) operations versus data submission (POST) operations?Within the 5-second response time constraint, what would be the most effective retry strategy, if any?Are there any additional best practices you would recommend for improving the resiliency and user experience of these integrations?
At present, I occasionally encounter exceptions while fetching data through the GET API and, at other times, while executing the POST API.
I would greatly appreciate your insights on the most effective and resilient approach for handling these situations.
Thank you for your guidance.
Yes, I would recommend treating the GET and POST APIs differently. Retry and Circuit Breaker should not be applied blindly to every exception.
1. GET API – Dashboard
For a GET API that retrieves historical data, retry logic can be useful for transient failures, such as:
For these cases, you can use a limited retry.
2. POST API – Save Operation
Your understanding is correct. I would not automatically retry a POST simply because an exception occurred.
The main concern is that the first request may actually have succeeded on the target system, but the response was lost because of a timeout/network issue. Retrying the same POST could therefore create a duplicate transaction.
For POST operations, a better approach is:
User clicks Save - POST API - Success → Continue↓Transient/Unknown failure-Log the request + response/error-Show appropriate message to user
If the external API supports idempotency keys/request IDs, then automatic retry becomes much safer. You can send a unique transaction ID with the request, allowing the receiving system to recognize duplicate requests.
3. Circuit Breaker
I would consider Circuit Breaker for both GET and POST, but primarily when the external service has a pattern of repeated failures.I would avoid aggressive retries from the UI.
But the exact timeout should depend on the external API's normal response time.
For longer-running operations, I would move the processing to an asynchronous/background process instead of keeping the user waiting.
Thank you for the clarification. Your guidance has helped clear up my confusion and provided a better understanding of the recommended approach.