Why (Refresh Auth Workflow) not getting triggered when API responds with 401/403?

đź’¬ App Building
5

Hi @CoderNadir,

You’re not wrong in how you expect it to work – with Custom Auth, Retool should:

  1. Send the request using the resource

  2. If the response is non-200 (401/403 is just the common example), run the Refresh auth workflow

  3. If refresh succeeds, retry the original request once Retool Docs+1

So if your refresh flow is never running, it usually means one of these is happening:

1. The failing query isn’t actually using the resource’s auth

Make sure, on the query that fails when the token expires:

  • Resource is set to your Custom Auth resource

  • Authentication is set to Use resource’s authentication

  • You are not overriding the Authorization header manually in the query (if you hard-code the header, Retool won’t inject or refresh it)

If you’re calling the API directly via a REST query or JS fetch instead of using the resource, the refresh flow won’t ever run.

2. The 400 you see in DevTools is Retool’s own error, not the API’s 401/403

The status code in the browser Network tab is for the call from your browser → Retool, not necessarily the call from Retool → your API.

Open the query in Retool and look at the Response / Preview panel:

  • If you see your API’s 401/403 there, refresh should be eligible to run.

  • If you see a 400 with a Retool-level error (config issue, CORS/proxy error, etc.), then the request never reached the point where the custom-auth refresh can trigger.

In that second case, fix whatever is causing the 400 (base URL, headers, CORS with SuperTokens, etc.) so that the actual 401/403 from your API reaches Retool.

3. Refresh flow runs, but doesn’t update your tokens

The refresh workflow not only has to call SuperTokens successfully, it also has to overwrite the same variables your main auth flow uses.

On the resource page:

  1. Click Test auth workflow → note the values/timestamps of your defined variables (ACCESS_TOKEN, REFRESH_TOKEN, etc.).

  2. Click Test refresh auth workflow → check that those variables get new values. If not, add Define variable steps in the refresh flow so it writes back to the same variable names. Retool Forum+1

If the variables don’t change, the second attempt will still fail with 401/403 and it’ll look like “refresh never ran”.

4. Make sure you’re not testing this only from a Workflow

Right now, resources with custom auth/refresh are supported when used from apps; usage from Workflows has limitations and the refresh flow generally does not run the same way there. Retool Forum+1

Quick checklist

  • Query uses the Custom Auth resource and “Use resource’s authentication”

  • No manual Authorization header in the query

  • In the query Response tab, your API actually returns 401/403 (or another non-200)

  • Testing the refresh auth workflow updates the token variables

  • You’re reproducing the issue from an app, not only from a Workflow

If all of the above looks correct and the refresh flow still never fires, then this might be a bug.

If anybody from retool can help check if there’s anything specific about SuperTokens here, or inspect logs for this resource? It would be great to confirm whether the non-200 responses are reaching the custom auth layer and whether the refresh workflow is being invoked server-side.