Read a Google Sheet from a Next.js Server Component

A spreadsheet as your content layer

Not every Next.js app needs a CMS or a Postgres box behind it. For marketing pages, a catalog, docs, or a directory, the content is a table your team would rather edit in a spreadsheet than a database admin. The friction is getting that sheet into your app as clean, typed data — Google's own API means a Cloud project, OAuth, and cell-range parsing.

PasteSheet removes that. You fetch() a normal JSON endpoint from a Server Component or a build-time data function, and the rows come back typed and keyed by column. Because it is a server fetch, your keys never touch the browser, and Next.js caching keeps it fast.

Where it slots in

The same endpoint fits every Next.js data-fetching path:

• App Router: await fetch() in an async Server Component.
• ISR: pass next: { revalidate } to rebuild the page on a schedule.
• Pages Router: call it from getStaticProps or getServerSideProps.
• Client-side: fetch a public endpoint directly for a live dashboard or search box.

Fetch in a Server Component with ISR

Type the row shape, fetch the endpoint with a revalidate window, and render — no client JavaScript required:

type Product = { slug: string; name: string; price: number }

export default async function Products() {
  const res = await fetch(
    "https://pastesheet.com/your-endpoint/Products?sort=name",
    { next: { revalidate: 300 } } // ISR: rebuild every 5 minutes
  )
  const { data }: { data: Product[] } = await res.json()

  return (
    <ul>
      {data.map((p) => (
        <li key={p.slug}>{p.name} — ${p.price}</li>
      ))}
    </ul>
  )
}

Getting the caching layers to agree

There are two caches in this stack and they are easy to confuse. The endpoint TTL controls how often PasteSheet re-reads Google. The ISR revalidate window controls how often Next.js rebuilds the page. Worst case, an edit waits for both — so a 5-minute TTL behind a 5-minute revalidate can take up to ten minutes to appear.

The fix is to make one of them clearly the shorter. Set the endpoint TTL below your revalidate window and the ISR window becomes the only number you have to reason about. For content that must be near-instant, drop to revalidate: 0 (or cache: 'no-store') and let the endpoint's own cache do the protecting — you still are not hitting Google on every request.

Practical notes for a real app

• Type the response, do not trust it. Column inference is good, but a colleague can type N/A into a number column. Validate at the boundary with Zod if the render would break on a bad value.
• Use the alias, not the header. Querying job_title instead of Job Title (public) means someone can retitle the column for readers without breaking your build.
• Filter server-side. ?status=live&limit=50 in the URL beats fetching everything and filtering in JS — less payload, less work in the render.
• Fail soft on build. Wrap the fetch so a transient error falls back to the last good data rather than failing the whole static build.
• Keep the key server-side. A private endpoint's bearer token belongs in an env var read by a Server Component — never in a client component or a NEXT_PUBLIC_ variable.
• Set the row cap deliberately. A sheet that grows past your plan's cap truncates silently in a paginated UI unless you page through it.

When a sheet is the wrong data source

This pattern is a good fit for read-heavy, human-edited, tabular content — catalogs, docs indexes, directories, pricing. It is a poor fit the moment you need writes from the app, per-user data, relational joins, or transactional guarantees. A sheet has no constraints, no migrations, and no concurrency story beyond "last edit wins".

The honest test is whether a non-technical person editing a cell is a feature. If yes, a sheet is often better than a database. If the thought makes you nervous, you want a real backend.

Read-only, no Google Cloud project

Because the endpoint is read-only by design, it is safe to expose publicly or hand to a teammate: consumers can read and query the data but can never change the sheet. And there is no Google Cloud project, OAuth screen, or service account to set up — you paste a share URL and get a live API.

What it costs

Frequently asked questions

Sources

• Authorize requests — Google Sheets API — Google
• Usage limits — Google Sheets API — Google

Related use cases