Google Sheets API vs Grist

Google Sheets API

Batch updates apply atomically and count as one request, and the drive.file scope limits an app to files the user picks. Quotas are 300 reads and 300 writes a minute per project, reads are by range with no row filter or paging, and a person must complete OAuth consent first.

Grist

OAuth tokens carry seven scopes, can be limited to chosen documents and expire after an hour, and the REST API has a public OpenAPI file with an add-or-update call. No status page, SLA terms, DPA or security.txt was found, and the docs say the hosted service has no SOC 2 or ISO 27001 audit.

Google Sheets API

1. Ask for drive.file where the user picks the files. spreadsheets and spreadsheets.readonly are sensitive scopes and need extra verification for a public app
2. Send valueInputOption=USER_ENTERED to write formulas. With RAW the string =1+2 is stored as text
3. Put related changes in one spreadsheets.batchUpdate. It counts as one write request and none of it applies if any request is invalid
4. Pass ranges and a fields mask on spreadsheets.get and leave includeGridData off for large files
5. Back off exponentially on 429 and 503, and keep to one request a second per spreadsheet. After a timeout on values.append, read the range before retrying

Grist

1. Connect through OAuth, not an API key. Ask for doc:read alone for reading, and have the user pick Selected resources on the consent screen
2. Keep doc.schema:write off unless needed. The docs say formula editing lets its holder read any data in the document whatever the access rules
3. Send requests for one document one at a time. The eleventh concurrent request gets 429, and no Retry-After header is documented
4. Use PUT /api/docs/{docId}/tables/{tableId}/records with require to add or update by key, so a retried write doesn't create a duplicate row
5. Use the /records endpoints, not the deprecated /data ones, and split large writes to stay under the 1 MB body limit