Gmail API + OAuth 2.0 - second auth flow does not save access/refresh token

đź’¬ Queries and Resources
, , ,
1

My goal:
Retrieving data from the Google API (Gmail history) using a REST API resource in Retool.

Issue:
I configured a REST API resource in Retool with OAuth 2.0 authentication. The first “Connect with OAuth” flow worked: I logged into my Google account and got a valid access token and refresh token. Then I revoked both tokens manually to test re-authentication. After revoking, I clicked “Connect with OAuth” again, went through the Google login/consent flow, but when I returned to Retool the “See token status” panel showed no access token or refresh token. In other words: the second OAuth flow did not result in any tokens being saved.

Steps I’ve taken to troubleshoot:

  1. Configured the REST API resource with Google OAuth 2.0 credentials.

  2. Performed initial “Connect with OAuth,” authenticated — received access token and refresh token.

  3. Confirmed both tokens were present under “See token status.”

  4. Manually revoked both tokens.

  5. Ran “Connect with OAuth” again, logged in to Google, granted consent.

  6. Immediately opened “See token status” — saw no token values.

    image
    image710Ă—395 17.5 KB

  7. Verified I did not manually set or override any Authorization header.

  8. Searched the community for similar reports; found some, but those seem outdated.

Additional info:

  • Retool deployment type: Cloud

  • OAuth consent screen in Google Cloud: I published the app (moved from “Testing” to “In production / Published”)

  • When the app was in “Testing” mode, I previously received refresh tokens that included a “refresh_token_expires_in” field (7-day expiry). After publishing the app, new token responses no longer include that field — not sure if that means no expiry, or a change in what Google returns.

  • Resource configuration:

    image
    image990Ă—1337 93.8 KB

What I’m asking

  • Has anyone recently (2024–2025) experienced the same behavior with Retool + Google OAuth / Gmail API: first OAuth works, but subsequent re-auths don’t store tokens?

  • If yes, did you find a configuration (scopes, OAuth settings, consent screen mode, “access_type=offline”, prompt, etc.) that reliably works for re-authentication?

  • Is there a known issue or regression in Retool’s OAuth 2.0 flow for Google APIs (especially Gmail)?

Thank you in advance for any insight or help.

3 Likes
3

+1

4

I was having a similar issue and it seemed to be an issue with the oauth callback. For a shared credentials resource it should be https://oauth.retool.com/oauth/oauthcallback. Note that /user/ isn’t there.

It seems that when you save the resource it’s switching the callback to the non-shared credential callback. I was able to temporarily get things working by toggling the shared credentials checkbox off then back on then reconnecting with oauth before saving or exiting out of the resource.

It would have reloaded the page after your first auth flow which caused the callback to change. That’s why it succeeded the first time but not after you revoked and retried.

1 Like
5

Thanks for this❤️, your workaround actually fixed the problem for me. I toggled “Share credentials between users” OFF, then back ON, and only after that clicked “Connect with OAuth” again, and this time Retool did save both the access token and refresh token correctly.

What makes this especially strange is that the re-connection only works after toggling OFF and then ON again. The fact that the callback URL changes depending on that toggle, and that saving the resource seems to silently switch it, definitely feels like a bug.

This workaround helps, but it’s not something users should have to do, and it’s easy to miss. I think the Retool team should really look into this, because it makes OAuth flows with Google APIs unreliable unless you know this trick.

6

Awesome, glad to hear that helped!

I raised it as a bug here. Would appreciate a +1 on that thread to gain some visibility. Hopefully one of the retool team can pop in and link them or provide a timeline on a fix soon!

1 Like
7

Hi all, I believe a fix went out for this on version 3.319, let us know if you're still having issues!

1 Like