Guides / Prompting and shipping

How to Connect Google Sheets to Your App

Read and write Google Sheets from your app: service accounts vs OAuth vs API keys, the Sheets API calls, quotas, formula safety, and when to move to a database.

Mythex Team · 2026-09-29 · 6 min read

To connect Google Sheets to your app, enable the Google Sheets API in a Google Cloud project, create a service account, share the spreadsheet with the service account's email address, and store its key as a server-side secret. Your server then reads rows with spreadsheets.values.get and adds rows with spreadsheets.values.append. If users need to connect their own sheets, use OAuth instead, and if the sheet is fully public, a simple API key is enough for reading.

This guide covers which method fits, the calls you need, the quotas and gotchas, and prompts for an AI app builder. Google details are from Google's developer documentation as of September 2026.

Why connect a sheet at all

Common reasons:

• Keep the team's workflow. Staff keep editing a price list or schedule in Sheets; the app shows it.
• Collect data where people already look. New signups, orders or form responses land as rows.
• Reporting. Export app data to a sheet for people who live in spreadsheets.
• A stepping stone. Start from the sheet, then move to a proper database. See how to turn a spreadsheet into an app.

Choose how your app signs in to Google

Google's credentials guide describes three types:

For most apps, a service account is the right choice: one set of credentials, owned by you, with access only to the sheets you explicitly share with it.

Step by step with a service account

1. Create or pick a Google Cloud project and enable the Google Sheets API.
2. Create a service account and a key for it. The key is a JSON file; treat it like a password.
3. Share the spreadsheet with the service account's email address, as Viewer for read-only or Editor to write. Google's guide says this is done through the normal sharing screen.
4. Store the key as a secret on your server, for example GOOGLE_SERVICE_ACCOUNT_JSON, plus the spreadsheet ID (the long string in the sheet's URL) as SHEET_ID.
5. Call the API from the server with Google's client library for your language.
6. Cache reads if many visitors see the same data, so you don't hit the quota.

The calls you'll use

From Google's guide to reading and writing values:

Ranges use A1 notation. Google notes that a range without a sheet name, like A1:B2, applies to the first sheet, so name the tab explicitly to avoid surprises when someone reorders tabs.

RAW vs USER_ENTERED

Writes need a valueInputOption:

• RAW stores exactly what you send, as text. =1+2 is stored as the text =1+2.
• USER_ENTERED treats input as if typed into Sheets: dates become dates and =1+2 becomes a formula.

If you write text that users typed into your app, use RAW. With USER_ENTERED, someone could submit a formula that runs when a colleague opens the sheet.

Quotas and errors

As of September 2026, Google's Sheets API limits page lists:

There's no daily limit as long as you stay within the per-minute quotas. Going over returns 429: Too many requests, and Google recommends truncated exponential backoff: wait longer after each failed attempt, with a random delay, up to a maximum. A single request that takes over 180 seconds times out.

In practice: don't call the API on every page view. Cache the sheet's data for a minute or more, batch reads with batchGet, and batch writes where you can.

Options and trade-offs

For anything with many users or sensitive data, a database is the better source of truth. See what a database is.

Prompts to give your AI builder

Reading a sheet:

Show the "Menu" tab of our Google Sheet on the menu page. Use the Google Sheets API from the server with a service account whose JSON key is in the secret GOOGLE_SERVICE_ACCOUNT_JSON, and the spreadsheet ID in SHEET_ID. Read the range Menu!A2:D (name, description, price, category). Cache the result for 5 minutes. If the API fails, show the last cached version. Never send the key to the browser.

Writing rows:

When someone submits the contact form, save it to our database and also append a row to the "Leads" tab (date, name, email, message) using spreadsheets.values.append with valueInputOption RAW. If Google returns 429, retry with exponential backoff; if it still fails, keep the lead in the database and retry later.

Common mistakes

• Forgetting to share the sheet with the service account email. The API then returns a permission error even though the key is fine.
• Key in the frontend or the repository. The JSON key grants access to every sheet shared with it. See how to keep API keys safe.
• Using USER_ENTERED for user input, which allows formula injection.
• Calling the API on every request and hitting the per-minute quota at the first traffic spike.
• Depending on column positions. Someone inserts a column and the app reads the wrong data. Read the header row and map by name, or lock the header.
• Sharing the sheet more widely than needed. "Anyone with the link" makes it public.
• Using a sheet as a multi-user database. Concurrent writes and missing permissions cause lost or leaked data.

Checklist

• Sheets API enabled; service account created
• Sheet shared with the service account email at the lowest role needed
• Key and sheet ID stored as server-side secrets
• All calls made from the server
• Tab names used in ranges
• RAW used for user-provided text
• Reads cached; 429 handled with backoff
• App degrades gracefully if Sheets is unavailable
• Decided which side is the source of truth

Google Sheets in Mythex

Mythex has two different ways to work with Sheets. Connectors link your Google account to Mythex so the agent can use it while you build, for example reading a sheet to build a dashboard from it; the docs say the credential stays with Mythex's connection service and never lands in your code (see Connectors, and approve every permission Google asks for). For the published app to read or write a sheet on its own, the dependable route is the one in this guide: a service account key stored as a project secret and Sheets API calls from your server, as in Integrate any API. If you're outgrowing the sheet, ask the agent to move the data into the project's database and build a dashboard on top of it.