​@lombardoalejandro05 Ooooh. That’s a tricky one. 

The only way I can think of to monitor this is to using an application like Wireshark. It can “see” the data being transferred between the bot agent and the target system. It might be able to let you know if there is some sort of error code coming back from Google (e.g., a 500 or 403), or if Google just isn’t responding at all.

Also, double check that you can manually connect (through a browser) to Google Sheets and perform the same action without error.

I opened the Google Sheet through an URL and I got an error on that line that says: An unexpected error occurred, begin 39, end -1. Please contact system administrator.

Hi ​@lombardoalejandro05,

As per my understanding, the issue might be likely causing by any of the following:

1. Interactive OAuth on an unattended Runner
   If the Connect action is set to Authorization code (legacy, attended), the Google consent window needs a visible desktop. On an unattended Bot Runner (no interactive session), that dialog can’t appear, so the action sits at “Connecting/Active” and never proceeds. The recommended approach for unattended runs is Control Room–managed OAuth2 with a shared token.

2. Browser Prompt: When executing the command to open the Google Sheet, check if a browser window opens with an Allow button. If so, make sure your bot has logic to handle it.

3. OAuth connection not authenticated / wrong token type
   If you’re using a User‑specific token, it has to be authenticated (status Active) in My settings → OAuth connections before the bot runs; for fully unattended runs, use a shared token so the bot doesn’t wait on user consent.

4. Using the deprecated G‑Suite Apps package
   Only the Google Sheets package is supported going forward; the older G‑Suite Apps package is deprecated and can lead to connection problems. Make sure your bot uses Google Sheets: Connect.

5. Network/Firewall blocking Google endpoints
   Your runner must reach Google OAuth and Sheets endpoints. Ensure outbound HTTPS to:

• https://accounts.google.com and https://oauth2.googleapis.com/token (OAuth)
• https://sheets.googleapis.com (Sheets API)

5. Outdated package or Bot Agent
   An older Google Sheets package or Bot Agent can cause odd behavior. Update packages in Manage → Packages and keep Bot Agent aligned with your Control Room version.

6. Redirect URI mismatch (if using Authorization code mode)
   When you do use an authorization code, Google’s OAuth client must include the redirect URI http://localhost:8888/Callback. A mismatch can stall the handshake. (For Control Room–managed OAuth, use the Control Room’s callback URL.)

Note: Google Sheets package actions also include a per‑action “Wait for action to complete” setting (default ~10 minutes) for reads/writes; if the sheet doesn’t open in time the task moves on. That won’t fix an OAuth hang, but it’s good to know once you’re past Connect.

Hi ​@lombardoalejandro05 

I faced a similar issue while working with Google Sheets in a previous project. Here’s the workaround that helped me resolve it:

1. Credential Authentication: Ensure that the credentials you're using are properly authenticated. Try logging in manually with those credentials to confirm they’re active and authorized.

2. Browser Prompt: When executing the command to open the Excel file, check if a browser window opens with an "Allow" button. If so, make sure to click it to grant the necessary permissions.

Following these two steps should help resolve the issue.

Im getting an Error 400: redirect_uri_mismatch. Only when I run it on my botrunner, which is a server in a another country. It doesn’t make sense since my Google account is logged on that server, and the bot runs just fine on sandbox. On GCP I have http://localhost:8888/Callback

I access the server by remote access and by the time I click run, the session closes, thus I cannot check for the window, even tho Im getting an error 400: redirect_uri_mismatch. It doesn’t make sense.

Hello, ​@Padmakumar.

In my case, the OAuth connection has been configured correctly. However, after exactly 60 minutes, the connection/token expires, requiring me to re-login from the Control Room. What I’m missing?

The behavior you describe (connection works immediately, but the token always expires after exactly 60 minutes and forces re-login) is not a Control Room bug. It’s the expected OAuth behavior when only an access token is issued and no refresh token is available.

Why this happens (brief)

• Google issues access tokens that expire after ~3600 seconds (1 hour). If your integration was authorized only for "online" access (no refresh token), the Control Room has no way to get a new access token automatically, and the user must re-authorize after 60 minutes.
• To avoid re-login, you need a refresh token (offline access) or use a service account (server-to-server) so no interactive re-login is required.

What you should do (two options)

1. Enable a refresh token (recommended if you need to access users' personal accounts)

• In the OAuth authorization flow for your Google OAuth Client, request offline access by adding:
  • access_type=offline
  • and if needed prompt=consent (to force Google to issue a refresh token if one was previously issued/revoked)
• Ensure your OAuth client is set up in Google Cloud Console:
  • Enable the Google Sheets API (and Drive API if you need Drive-level scopes)
  • Create OAuth credentials (OAuth Client ID) and set the Control Room callback/redirect URI exactly as the Control Room expects
  • Set the proper scopes (e.g. https://www.googleapis.com/auth/spreadsheets or spreadsheets + drive scopes)
• During initial authorization, show the consent screen; Google will then return a refresh_token along with the access_token. The refresh token can be used to obtain new access tokens automatically when the 1-hour access_token expires.
• Make sure the Control Room or your connector stores the refresh_token securely (Credential Vault or equivalent) and uses it to refresh access tokens—if the Control Room connector does not store the refresh token, you will still be forced to re-login.

2. Use a Google service account (recommended for unattended, server-to-server automation)

• Create a service account in Google Cloud Console and download the JSON key.
• Share the Google Sheet(s) with the service account’s email (or use domain-wide delegation + impersonation for G Suite/Workspace domain-wide access).
• Configure the Control Room connector to use the service-account credentials (no interactive OAuth; tokens are obtained server-to-server and can be refreshed automatically).
• This avoids interactive login and the 60-minute re-login problem entirely for automation scenarios.

To ensure you receive refresh token, you must have following. Otherwise you will not receive refresh token and will have to authorize via browser every time(or OAuth connection in Control room)

https://accounts.google.com/o/oauth2/auth?prompt=consent&access_type=offline

Hello ​@Bot Dev .

Yes, I’m using that authorization URL but not success. 

Thanks

How can I validate this point:

“Make sure the Control Room or your connector stores the refresh_token securely (Credential Vault or equivalent) and uses it to refresh access tokens—if the Control Room connector does not store the refresh token, you will still be forced to re-login“

?

1. Connect action setup

   • In your bot, use Google Sheets → Connect with OAuth2 Authentication Mode = Control Room managed.
   • Click Pick and select your OAuth connection.
   • For unattended runs, choose Token type = Shared; for attended runs, User‑specific (make sure it shows Active under My settings → OAuth connections). 

2. Minimal bot to run

   • Connect (as above, with a session name).
   • Open the spreadsheet using the Spreadsheet ID (more reliable than the URL).
   • Get single cell (e.g., Sheet1!A1) or Get the number of rows.
   • Disconnect.
     The “Open by ID” guidance and field definitions are in the official docs. 

3. First run (T0)

   • Run the bot once to confirm it works now. No prompts should appear if CR OAuth is configured correctly. 

4. Second run after token expiry

   • Wait 65–70 minutes (longer than typical access‑token lifetime).
   • Run the same bot again—without re‑authenticating in Control Room.
   • Expected result: It should work without any login prompt. This demonstrates Control Room used the stored refresh_token to mint a fresh access token on your behalf. 

Note: When using User‑specific tokens, ensure the connection shows Active under My settings → OAuth connections before your first run, and use Shared tokens for unattended scheduling to avoid interactive consent.