Coda (Superhuman Docs) vs Grist

Coda (Superhuman Docs)

API tokens can be limited to one doc or one table and to read or write, and the OpenAPI description covers 125 operations with 429 on almost all. Writes are queued and answered with 202, so each needs a status check. The REST API has no idempotency keys or official client libraries, and the MCP server is in beta.

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.

Coda (Superhuman Docs)

1. Poll /mutationStatus/{requestId} after every row write. A 202 means queued, and the edit can still fail
2. Send X-Coda-Doc-Version: latest when a read must reflect recent edits, and handle the 400 it returns when the snapshot is behind
3. Use keyColumns on POST .../rows so a retried insert updates the same row instead of adding a duplicate
4. Ask for a token restricted to the one doc or table and to read access where the task allows. An unrestricted token can do anything its owner can
5. Read MCP tool names from the tool list at run time. The vendor says names and parameters can change during the beta

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