SheetDB vs Google Apps Script: building a JSON API on a Google Sheet

Short answer: a Google Apps Script web app is free and lives inside your spreadsheet, but you write and maintain the API yourself: routing in doGet and doPost, JSON parsing, filtering, auth and error handling, and it only supports GET and POST. SheetDB gives you a ready REST API for the same sheet (GET, POST, PATCH, PUT, DELETE) with search, caching, CORS handling and access controls, in exchange for a request-based plan with a free tier. Pick Apps Script for custom logic and Workspace automation; pick SheetDB when you just need the sheet's rows over HTTP.

At a glance

Apps Script behaviour and quotas as documented by Google, checked October 2026. Quotas depend on the account type and can change.

Why people build APIs with Apps Script

Apps Script is already there: open the sheet, choose Extensions → Apps Script, write a function, deploy. There is no separate service, no bill, and the code runs next to the data with full access to the spreadsheet, Gmail, Drive and Calendar. For a personal project, an internal tool or a webhook that does more than store a row (send an email, create a calendar event, recalculate a summary), it is a great fit and SheetDB does not replace it.

What you take on when the script becomes an API

The trouble starts when a website, an app or another team depends on the script as if it were a real API:

• Every feature is code. Filtering by a column, paginating, updating one row, deleting another: each one is a branch in doGet or doPost that you write, test and keep in sync with the sheet's columns.
• Two methods only. Web apps answer GET and POST, so updates and deletes are tunnelled through POST with an action parameter. Clients that expect REST conventions need adapting.
• Browser calls. A POST with application/json triggers a CORS preflight that Apps Script does not answer. The web app URL also answers with a redirect to script.googleusercontent.com, which some HTTP clients and no-code tools do not follow by default.
• Auth. "Anyone" means anyone with the URL can call the script, including the write path. The usual fix is a secret query parameter checked in code, which ends up in logs and browser history.
• Deployments. Changes go live only after you update the deployment; creating a new deployment changes the URL. It is easy to test one version and serve another.
• Performance. Each request starts the script and reads the sheet. Without CacheService code, a busy page means many executions and slow responses.

SheetDB takes over exactly that plumbing. You get read, search, create, update and delete endpoints, caching, permissions and authentication without writing them, and the sheet stays an ordinary Google Sheet you can still automate with Apps Script.

How simple it is with SheetDB: read adults, add a row

The task: a sheet with columns id, name, age, comment. Return the people older than 18 as JSON and accept new rows. With SheetDB there is no script to write and nothing to deploy:

• No backend code. No doGet, no doPost, no JSON parsing, no routing by action parameter.
• No deployments. The endpoint URL stays the same; there is no deployment to update and no version to keep in sync.
• No CORS workarounds. Send real application/json from the browser; the preflight is handled for you.
• No filtering in your code. The condition goes into the URL and only matching rows are returned.

Here is the whole thing, using plain fetch(). It runs in Node.js or in the browser, and the endpoint below is a real demo API you can try right now:

const api = 'https://sheetdb.io/api/v1/58f61be4dda40';

const params = new URLSearchParams({ age: '>18' });
const adults = await fetch(`${api}/search?${params}`).then((response) => response.json());
// [{ "id": "2", "name": "Alex", "age": "24", "comment": "" }, ...]

await fetch(api, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ data: [{ id: 'INCREMENT', name: 'Mark', age: '35', comment: '' }] }),
});

That is the entire integration: one GET to /search?age=>18 returns the adults, one POST with a JSON body appends Mark, and INCREMENT fills in the next id for you. The new row shows up in the spreadsheet immediately.

Building the same as an Apps Script web app means writing and maintaining that logic yourself, and it still would not have auth, input validation, proper error responses, update, delete or caching. With SheetDB those are already there as endpoints or settings: PATCH /api/v1/{id}/id/4 updates the row whose id is 4 and DELETE /api/v1/{id}/id/4 removes it (update, delete). For a form, see HTML form to Google Sheets; to show rows on a page, see display Google Sheets on a website.

FAQ

[
  {
    "id": "1",
    "name": "Tom"
  }, …
]