Guides · Setup
Connect Google Sheets to Outloop
Last updated:
In short
Connecting Google Sheets to Outloop means signing in to Google once from Outloop in your browser, then approving the exact spreadsheets each client workspace is allowed to touch.
Outloop mints and stores the refresh token host-side in the macOS Keychain — there is no token to copy. Agents then read and write cells, formulas and formatting in only the spreadsheets you approved for that workspace; a request naming any other spreadsheet is denied before any call reaches Google, and every request is audited with secret_exposed:false.
What this setup gives you
Agents that can do real Sheets work inside the client files you approved — and nothing outside them. Outloop holds the Google credential locally, decides which spreadsheet each workspace may reach, and audits every request.
- →An agent can create a spreadsheet, then write values, formulas and formatting into an approved spreadsheet.
- →Each client workspace is pinned to its own spreadsheets — one agency Google account, many separated clients.
- →The refresh token is minted host-side and never appears on your clipboard, in a screenshot, or in a prompt.
- →A wrong-file request is refused before any call reaches Google, not after.
What you need before starting
- ✓Access to a Google Cloud project with the OAuth consent screen configured.
- ✓A Client ID and Client Secret for your first Google connector. After that, Outloop reuses the saved Google OAuth app and never asks for the secret again.
- ✓The Google account that can open the client spreadsheets — you will sign in as it in your browser.
- ✓The spreadsheet IDs the workspace should be allowed to touch (the segment between
/d/and/editin the spreadsheet URL). - ✓Outloop installed and activated, with a workspace selected.
Which Google account connects what
Three separate identities — keep them apart
Most failed Google Sheets setups are one confusion: assuming the Google account that manages the Cloud project is also the account that can open the client's spreadsheets. It does not have to be, and often should not be.
- 1
The Google Cloud project and OAuth app
This owns the Client ID and Client Secret. It can belong to your agency or to your client — Outloop does not care which, and cannot tell the difference.
cloud-admin@agency.example— manages the Google Cloud project - 2
The connected Google account
This is the account you pick in Google's own chooser during the browser sign-in. It is the account that must actually own or be able to open the client's spreadsheets.
data-owner@client.example— is chosen at sign-in because it owns the client's spreadsheets - 3
Outloop workspace access
This decides which workspace may use the stored credential, which resources it may reach, and which capabilities agents get. It is set in the Access Profile, after the sign-in succeeds.
In that example, cloud-admin@agency.example
created the OAuth app once, and every connector after it reuses that app — but the account you
actually sign in as is data-owner@client.example,
because that is the identity Google Sheets will check when an agent asks for a file.
- →If the app's audience is External and it is still in Testing, the account must be added as a Test user first.
- →If the audience is Internal, only accounts inside that Google Workspace organisation can sign in at all.
- →The Google Sheets API must be enabled in the Google Cloud project the app belongs to.
- →The account must genuinely have access to the client's spreadsheets. A successful sign-in proves identity, not reach.
1. Enable the Google Sheets API
In Google Cloud Console, open APIs & Services → Library, search
Google Sheets API, and click
Enable. Outloop calls it at
sheets.googleapis.com.
2. Create the OAuth client (once, for all Google connectors)
In Google Auth Platform → Clients, create a
Web application OAuth client and copy the
Client ID and Client Secret.
Google may show the secret only once; if you lose it, create a new one. Under
Authorized redirect URIs add Outloop's local callback — without it
the browser connect below fails with redirect_uri_mismatch:
http://127.0.0.1:44317/oauth2/callback
The full one-time Google Cloud walkthrough — project, APIs, the whole scope set in one paste, and the publishing-status step that stops a working connection expiring after about a week — is in Set up one reusable Google Cloud OAuth app. If you already have a saved Google OAuth app, there is nothing to create here. The scope this connector requests is:
https://www.googleapis.com/auth/spreadsheets openid email
The openid and
email scopes are how Outloop verifies which Google
account you actually connected — that identity check is Google OIDC, and it does not involve any Drive scope.
You only enter the Google OAuth app once
The first Google connector you set up asks for the Client ID and Client Secret from your Google Cloud OAuth client. Tick Save this Google OAuth app so other Google connectors can reuse it and every later Google connector — Gmail, Drive, Docs, Slides and Analytics GA4 — picks it from the Google OAuth app dropdown with no Client Secret to re-enter. The saved app is then listed under Authentication Profiles. When a saved profile supplies the app, Outloop shows “Using <client-id>. Its Client Secret comes from the saved app — nothing to paste. This connector still signs in separately and gets its own access.”
Reusing the app does not mean sharing one login. Each connector still opens its own browser sign-in and gets its own refresh token, its own scopes and its own connected account — so you can revoke or re-authenticate one connector without touching the others.
Shared agency app or workspace-dedicated?
Which setup should I choose?
There are two reasonable answers for Google Sheets, and the right one depends on who owns the Google Cloud infrastructure — not on how many clients you have.
Agency-global (shared OAuth app)
One OAuth app your agency owns, reused by every Google connector you add. This is the default and the right choice for most agencies.
- ✓Client ID and Client Secret entered once, then picked from a dropdown.
- ✓Every connector still runs its own Google sign-in.
- ✓Each one gets its own scopes, its own refresh token, its own connected account and its own revocation.
- ✓Reusing the app grants no data access by itself — workspace grants and Access Profiles stay explicit.
Workspace-dedicated
A separate OAuth client — or a separate Google Cloud project — for one workspace or one client.
- →The client owns the Google Cloud infrastructure and wants to keep owning it.
- →They need stronger administrative separation, or their own consent branding and audience rules.
- →They want separate quotas and their own lifecycle control.
- →The client's spreadsheets sit inside their own Google Workspace and their IT team wants the OAuth app to live there too.
A separate Google Cloud project is the strongest operational separation. A separate OAuth client inside the same project is lighter separation — useful, but the project is still shared.
3. Add Google Sheets in Outloop
In Outloop, open API Keys & Access → Add an API key and choose Google Sheets. The panel opens on Connect in your browser, with the Cloud Console detail in the collapsed Setup details — Google Cloud OAuth client, scopes and caveats and Before you connect disclosures.
Under Access to request from Google, choose the level:
- →Full spreadsheets — read, create, edit values, formulas and formatting (recommended)
- →Read-only spreadsheets
The full option is preselected because it is what most agency work needs; read-only is offered but never preselected. Then check the Google OAuth app dropdown — a saved profile supplies the app with no Client Secret to re-enter.
4. Connect the account in your browser
Click Connect Google Sheets in your browser. Google's own sign-in opens and shows an account chooser — pick the account that can open the client spreadsheets, then approve the consent screen. Google hands back to Outloop on a local loopback callback and Outloop mints and stores the refresh token host-side.
.env file.
5. Confirm the account and capabilities
Outloop shows Connected as the Google account you just used. Check it — this is the moment to catch a sign-in to the wrong account, before any agent touches client work.
Under Agents will be able to (change any time in the Access profile), these are on by default:
- ✓Read spreadsheets
- ✓Create new spreadsheets
- ✓Edit cells, formulas and formatting
And these are unchecked, marked ⚠, and only run if you turn them on:
- ⚠Erase the contents of cells
- ⚠Delete tabs, rows and columns
Then click Confirm — this is the approved account.
6. Save the Access Profile and approve the spreadsheets
OAuth is not the finish line — the Access Profile is
When Google Sheets hands you back to Outloop, the connector is authenticated but not yet authorized. Agents cannot use it until you make the authorization decision yourself:
- OAuth connected
- Confirm the account
- Open the Access Profile
- Choose account-wide or specific spreadsheet IDs
- Choose capabilities
- Save the Access Profile
- Copy the proof prompt
In the Access Profile you set two things. Reach — either account-wide, or a specific list under Approved spreadsheets. And capabilities — what agents may actually do inside that reach, with anything destructive left off unless you turn it on.
CUSTOMER_RESOURCE_PIN_REQUIRED before the credential is ever read.
This is the step that separates clients, and the one people skip. Connecting the account is not the same as
granting access to a file. On the connector's card, paste the spreadsheet IDs this workspace may touch into
Approved spreadsheets, one per line — the ID is the segment between /d/ and /edit in the spreadsheet URL.
Approved spreadsheets: 1AbCdEf... # client A — spreadsheet the agent may edit 2GhIjKl... # client B — a second approved spreadsheet
Or, in the Access section, choose Account-wide deliberately. There are only two modes, and the safe pinned one is the default. Then click Save Access Profile — until you do, Copy workspace run prompt stays disabled.
7. Run the first proof
Ask the agent for a safe read against an approved spreadsheet:
{
"tenant": "<WORKSPACE_ID>",
"service": "google_sheets",
"verb": "api_bridge.request",
"method": "GET",
"path": "/v4/spreadsheets/<SPREADSHEET_ID>?fields=spreadsheetId"
} Use a real spreadsheet ID that the connected account can open — never a guessed one. Success criteria:
decision: allow HTTP 200 spreadsheetId matches the approved spreadsheet secret_exposed: false audit entry exists
Only the last line completes the proof. A grant preflight that passes, or an OAuth callback that succeeded, is not runtime verification — the provider request has to succeed against a real resource first.
What happens when nothing is approved
Outloop fails closed here, which is the behaviour you want and the most common first confusion:
- →No approved spreadsheet and no explicit account-wide setting — every agent call is refused with
CUSTOMER_RESOURCE_PIN_REQUIRED. - →A spreadsheet that is not on the list — refused with
RESOURCE_ID_NOT_ALLOWED. - →Both refusals happen before the credential is read — no Google call is made, and nothing is charged against your quota.
- →Creating a new spreadsheet while pinned is refused too. Approve the new ID afterwards; Outloop never widens a pin by itself.
A file Drive can see is not a file Sheets can open
Google Drive and Google Sheets are separate connectors in Outloop, and they can be authenticated as different Google accounts. Finding a spreadsheet through the Drive connector therefore proves nothing about whether the Sheets connector's identity can open it.
- →Test with a spreadsheet that the exact account shown under Connected as on the Sheets connector owns or has been explicitly shared.
- →An HTTP 403 on one document is normally a file-permission result for that identity. On its own it does not prove a missing scope, a disabled API, or a broken connector.
- →"API Enabled" in Google Cloud does not prove a specific account can open a specific file. It only means the API exists for the project.
- →Prove access on a file you know that identity owns before you start changing scopes — changing scopes to fix a permission problem widens access without fixing anything.
See the Google Drive setup guide for the Drive-side boundary, and the Google Docs and Google Slides guides, which share this behaviour.
What bites people about the Sheets API
Access is only half the job. These are the Sheets-specific behaviours that make an agent's write land wrong even when the connector is working perfectly — worth putting in the agent's instructions up front.
RAW vs USER_ENTERED decides whether a formula is a formula
Every write carries a valueInputOption. With
RAW, Google's docs are explicit that the input is
not parsed — =1+2 lands as the literal text
=1+2. With
USER_ENTERED, the value is parsed exactly as if
typed into the UI, so =1+2 becomes a formula and
Mar 1 2016 becomes a date. An agent writing formulas or dates with
RAW produces a sheet full of inert strings that
looks fine until someone tries to sum it.
update, append and batchUpdate are three different operations
- →update writes one range, and takes
valueInputOptionas a query parameter. - →batchUpdate writes several discontinuous ranges in one call, and takes
valueInputOptionin the body instead. - →append looks for the last table within the range you name and adds rows after it, starting at the first column — so the row it writes to is Google's decision, not yours.
A1 notation without a sheet name means the first sheet
A range like A1:B2 with no sheet prefix targets
the first sheet in the spreadsheet — not the one that happens to be
open, and not the one the agent was told about. Have agents always qualify the tab
('Client Report'!A1:B2). And when a range names
multiple cells, the data has to fit inside it; a single cell like
A1 lets the write extend outward as needed.
Changing the account or the credential later
Changing the account or the credential later
Three controls on the Google Sheets connector look similar and do different things. Picking the wrong one is the most common way a working connector gets broken on purpose.
Re-authenticate
Reuses the OAuth app you already selected and refreshes the authorization for the account that is already connected.
When: Use it when the refresh token expired or was revoked and you want the same account back.
Safety: It must not quietly become an account switch. If Outloop finds a different account at the other end, it reports the mismatch and keeps the previous token.
Connect as a different Google account
Keeps the same Client ID and Client Secret and opens Google's account chooser so you can pick another identity.
When: Use it when the wrong account was connected, or when the client moved the data to a different Google account.
Safety: The stored token is replaced only after Outloop positively verifies that the newly connected identity is the one you intended. A mismatch, a missing identity, a failed verification or a cancelled sign-in all leave the previous credential exactly as it was.
Replace the full credential
Swaps the OAuth app itself — a different Google Cloud project, Client ID or Client Secret.
When: Use it when the OAuth app is changing hands, or a client is moving the connector onto their own Cloud project.
Safety: This is not the same as choosing another Google data account. Confirm with "Sign in and replace" only when you actually mean to change the app.
Verified vs not claimed yet
"Verified" here means a real proof passed through Outloop in a workspace — it is never a product-level claim about the connector.
- Verified A full real workflow through Outloop — created a spreadsheet, wrote values, formulas and formatting, and read them back — using files created for the proof.
- Verified An audited read through a pin created in the dashboard:
decision: allow, HTTP 200,secret_exposed: false. - Verified Wrong-resource denial (
RESOURCE_ID_NOT_ALLOWED) and no-pin denial (CUSTOMER_RESOURCE_PIN_REQUIRED), both at zero Keychain reads. - Verified Several Google connectors sharing one OAuth app, each holding its own distinct refresh token.
- Verified The audit contained no spreadsheet content and no secrets.
- Not claimed Anything on a machine other than the Mac this was proven on. Outloop is at controlled design-partner stage — reproduce it on your own Mac before relying on it for client work.
- Not claimed That a successful OAuth callback means the connector is ready. It means Google accepted the sign-in — nothing more until a provider request succeeds.
Troubleshooting
Google shows an account chooser
Expected. Outloop asks Google for the chooser on purpose, so a sign-in can never silently reuse whichever account your browser happened to be logged into. Pick the account that owns or can open the client's spreadsheets — which is often not the account that manages the Google Cloud project.
“Google hasn’t verified this app”
This appears because the OAuth app is your own and has not been through Google's verification. If it is your app and you trust it, expand Advanced and continue. If you do not know who owns the app, stop — that warning is doing its job, and clicking past an unknown app is not a routine step.
Which audience the app uses decides who can get that far at all. An External app in Testing only admits accounts added as Test users. An Internal app only admits accounts inside its Google Workspace organisation. For customer-facing production use, complete Google's verification rather than living in Testing.
The wrong Google account got connected
Use Connect as a different Google account on the connector. It keeps the same Client ID and Client Secret and reopens Google's chooser. The stored token is only replaced once Outloop verifies the new identity is the intended one — if it does not match, Outloop reports the mismatch and keeps the previous credential. Nothing is lost by trying.
A credential that works but sits on the wrong account is deliberately not marked runtime-verified for that workspace. Working and correct are different things.
BACKEND_AUTH_FAILED during connect
Google rejected the sign-in, so the new credential failed Outloop's safe verification. The important part: the previous credential is unchanged. Do not delete the connector, the OAuth app or the workspace as a first move. Check, in this order — that you signed in as the account that can reach the client's spreadsheets; that the account is admitted by the app's audience (a Test user on an External+Testing app); and that the API is enabled in the right Cloud project. Then try the connect again.
Reconnecting never asked for the Client ID and Secret
Expected. Disconnecting a Google Sheets credential does not delete your saved Google OAuth app profile — that is a separate object, kept on purpose so later connectors do not re-enter a Client Secret. Outloop reused it. If you specifically want a different app, pick another saved profile from the Google OAuth app dropdown, or create a new one and save it alongside. This is reuse working, not a stale credential silently retained.
“Copy workspace run prompt” is not available
The Access Profile has not been saved yet. Open the Access Profile, choose the reach and the capabilities, and click Save Access Profile — the run prompt becomes available once the authorization is recorded. OAuth succeeding is not the same as the workspace being authorized, and this is the step that closes the gap.
The connection stops working after about a week
If the OAuth app's audience is External and its publishing status is still Testing, Google expires refresh tokens for that app after roughly seven days. Two honest options: publish the app to In production, or use an Internal audience if everyone signing in is inside your Google Workspace organisation. Publishing may require Google's verification review depending on the scopes the app requests — that is Google's process and its outcome and timing are not ours to promise.
Every call returns CUSTOMER_RESOURCE_PIN_REQUIRED
The workspace has no approved spreadsheet and has not been set to account-wide. Add at least one spreadsheet ID under Approved spreadsheets, or choose account-wide deliberately — then save the Access Profile.
A specific file returns RESOURCE_ID_NOT_ALLOWED
That spreadsheet is not on the approved list for this workspace. Add its ID — and check you are adding it to the right workspace, because this refusal is usually correct.
A specific file returns HTTP 403 from Google
This is a Google answer, not an Outloop refusal — the request reached Google and that account was not allowed to open that file. Check the account under Connected as and share the spreadsheet with it, or connect as an account that already has access. Do not widen the OAuth scope to fix a sharing problem.
The agent created a file and then could not use it
Expected while pinned. Approve the new spreadsheet ID afterwards; Outloop never widens a pin on its own.
Rotate or revoke access
- →Narrow a workspace — remove spreadsheet IDs from Approved spreadsheets and save. Reach shrinks immediately; the credential is untouched.
- →Rotate the token — use Re-authenticate on the connector. Same account, fresh authorization.
- →Revoke everything for this connector — remove the Google Sheets credential in Outloop, then revoke Outloop's access for that account at myaccount.google.com/permissions. Do both: removing the local credential does not revoke the grant at Google.
- →Retire the OAuth app — delete the client in Google Auth Platform → Clients. This breaks every Google connector still using that saved app profile, so move them first.
Official Google documentation
- →Google Sheets API reference — endpoints, request shapes and field masks.
- →Sheets API OAuth scopes — what each scope permits.
- →OAuth app audience and publishing status — Internal vs External, Testing, and Test users.
- →Using OAuth 2.0 to access Google APIs — refresh-token behaviour, including the Testing-status expiry.
Outloop is an independent tool and is not affiliated with or endorsed by Google. See the security model, the Google Drive setup guide, or the full guide index.
Run Sheets agents on approved client files only.
Outloop is available with guided onboarding for AI agencies, operators, and dev shops.