Airtable vs Grist

Airtable

Tokens are limited by scope and by base, and the official MCP server at mcp.airtable.com covers records, schema, interfaces and automations in 40 tools. The REST API allows 5 requests a second per base with a 30-second lockout after a 429, writes take 10 records a call, and the Free plan stops at 1,000 calls a month.

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.

Airtable

1. Create a personal access token with only the scopes needed and add each base to it. A token with no base added sees nothing
2. Stay under 5 requests a second per base. After a 429, wait 30 seconds before the next call
3. Send writes in batches of 10 records, and use performUpsert with fieldsToMergeOn so a repeated call updates instead of duplicating
4. Use table and field IDs, not names, and set returnFieldsByFieldId so a rename doesn't break the call
5. POST to /listRecords when a filterByFormula would push the URL past 16,000 characters

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