Grist vs Teable

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.

Teable

Personal access tokens and OAuth tokens carry per-action scopes, and tokens can be limited to chosen spaces and projects. The public OpenAPI file covers 841 operations. Error responses beyond 200 and 201 are missing from that file, no idempotency keys were found, and the cloud allows 10 requests a second on every plan.

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

Teable

1. Send Authorization: Bearer <token> to https://app.teable.ai/api. A 403 with code restricted_resource usually means a missing scope or a project outside the token's list
2. Page records with take of 100 at most. Personal keys created on Teable Cloud since 10 September 2026 are capped at 100 a request
3. Ask for totals from /api/table/{tableId}/aggregation/row-count. Record lists stopped returning them by default on 2 September 2026
4. Keep to 10 requests a second, back off on 429, and check before retrying a failed write because no idempotency key exists
5. Pass fieldKeyType=id so renamed fields don't break writes, and leave typecast off unless values need converting