Workato Connector SDK - Refresh_On and Retry_On

[rlaib]

Hi,

In Workato's Connector SDK, upon receiving a response to a request, which key gets processed first, Authorization's refresh_on or, or an Action's retry_on?

Background:

I'm working with an API that, unfortunately, doesn't subscribe to using standardized HTTP codes for their broadly recognized purposes. Expired auth tokens return either 500 or 444, depending on the endpoint, and those same codes are reused across the API for transient/server-side errors.

I've implemented the refresh_on key using string matching:

refresh_on: [401,403,/Token Invalid/,/Invalid Token/]

But I can't do the same for the retry_on keys of various actions, as I don't have every potential error message available to me. Retry_on will have to be set up similar to this:

retry_on: [444, 500]

My worry is that, if the retry_on key of an Action is processed before the refresh_on key of Authorization, 444 or 500 token errors will trigger action retries instead of token refreshes.

Any insight would be helpful, thanks!

[shivakumara]

Hi @rlaib,
Here are my thoughts on my understanding retry_on_* and refresh_on

• Workato prioritizes refresh_on before retry_on_* when handling authentication-related errors.
•  If an API request fails with an authentication error (like 401 Unauthorized or 403 Forbidden), Workato will first check refresh_on in the Authorization block.
•  If token refresh succeeds, Workato will re-attempt the request with the new token before applying any retry logic.
•  If token refresh fails or isn't applicable, then retry_on_request or retry_on_response will take effect based on their conditions.
  
  Note:
  1. My suggestion would be, always differentiate your refresh_on codes and retry_on_* codes.
  2. Server or connectivity issues (500, 444, etc.) will be handled by retry logic, not token refresh.

[rlaib]

In my case, the API I'm making calls to is returning 444 and 500 as authentication errors, as well as server and connectivity errors. I can't tell you why they built their API this way, but I have to deal with it as such. I have no control over what error codes they return. When a 444 or 500 is returned as an authentication error, the message body contains the string 'Token Invalid' or 'Invalid Token'. I've added these to the refresh_on key:

refresh_on: [401,403,/Token Invalid/,/Invalid Token/]

When you specifically say that "If an API request fails with an authentication error (like 401 Unauthorized or 403 Forbidden), Workato will first check refresh_on,"  does this actually mean that Workato will always check refresh_on first, or only checks it first if it's a 401 or 403, even if there are other error codes / strings contained in the refresh_on key?