Grist vs NocoDB

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.

NocoDB

API tokens and MCP connections are limited by permission category and by base, and an MCP connection registers only the tools it is allowed. The v3 REST API has a public OpenAPI file. Requests are capped at 5 a second per user, REST writes take 10 records a call, and the Free plan stops at 1,000 API calls a month.

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

NocoDB

1. Create a fine-grained token limited to the bases and categories the task needs. Send it as xc-token or as a Bearer token
2. Stay under 5 requests a second across all tokens of one user. After a 429, honour Retry-After or wait 30 seconds
3. Send REST writes in batches of 10 records. The MCP record tools take up to 100, counted as one API call per 10 records
4. Write date filters with a sub-operator, such as (due_date,eq,exactDate,2026-06-01), and put no space after ~and or ~or
5. Use /records/upsert with a merge key so a repeated write updates the record instead of adding a duplicate