Authentication Options for Google Sheets REST APIs

Not every endpoint needs a lock on it

Authentication is often treated as a checkbox — add it everywhere, figure out the details later. With a Google Sheets REST API, the right approach depends on who owns the data and who is allowed to read it. SheetsAPI has three distinct tiers, and picking the wrong one either breaks your app or exposes data you meant to keep private.

Tier 1: Public endpoints — no authentication required

If the Google Sheet is already set to "Anyone with the link can view," the data is public. There is no reason to add authentication friction to the API layer on top of it.

Public SheetsAPI endpoints work exactly as you would expect: call the URL, get the data, no headers required. This is the right default for read-only public content — a pricing table, a public directory, a dataset you want to embed in a static site.

curl "https://sheetsapi.gkit.mreshank.com/api/spreadsheets/USER_KEY/Pricing"

The one thing to understand: "public" means public. Anyone who discovers the endpoint URL can read the data. For genuinely public content this is fine. For anything that should be restricted, use tier 2.

Tier 2: API key authentication — server-to-server calls

When the Sheet is private, or when you want to control which applications can call the endpoint, create an API key in your GKit dashboard. SheetsAPI issues keys in the format sk_... — scoped to your account's sheets.

Send the key in the Authorization header on every request:

curl "https://sheetsapi.gkit.mreshank.com/api/spreadsheets/USER_KEY/Employees" \
  -H "Authorization: Bearer sk_your_key_here"

This is the right tier for server-side code — a Next.js API route, a Cloudflare Worker, a backend that proxies data to your frontend. The key never appears in client-side JavaScript (where anyone can read it from the source), and you can revoke it from the dashboard if it leaks.

Do not use API keys in client-side code. If the key is in your React bundle, it is effectively public. For browser-to-API calls where the data is private, either proxy through your own server or accept that tier 1 is the appropriate fit.

Tier 3: OAuth — how SheetsAPI talks to Google on your behalf

When you sign in to GKit with Google, you grant SheetsAPI permission to read your Google Sheets via OAuth. This is not something you configure in your application — it is how the SheetsAPI worker itself authenticates to Google's Sheets API when your endpoint receives a request.

The flow: your app calls the SheetsAPI endpoint with your API key → SheetsAPI validates the key → SheetsAPI uses the stored OAuth token to call Google's Sheets API → Google returns the sheet data → SheetsAPI returns it to your app.

You never handle a Google OAuth token in your own code. The benefit is that you get access to private sheets (sheets that are not publicly shared) without managing Google credentials yourself, service account JSON files, or the Google Sheets API quota on your own Google Cloud project.

The OAuth token is scoped to read (and write, for POST/PATCH endpoints) your own sheets. Revoking GKit's access from your Google Account settings immediately cuts off all SheetsAPI access to your sheets.

Choosing the right tier

The short version: use public endpoints for public data, API keys for server-side private data access, and trust that the OAuth layer GKit manages is what allows any of this to work against private sheets at all.

If you are not sure which tier your use case is, start with the authentication docs — it has the specific header format and error responses for each tier.