Airtable Connector for Google Sheets
Introduction
Airtable holds the operational record and Google Sheets holds the report. The Airtable connector closes the loop in both directions: pull a base and table into Flookup Staging, deduplicate, standardise or match the records with the same tools you use on any sheet, then write back only the fields you changed.
Included with the 1-Year Pass and the Team Pass. The 1-Month Pass and the free trial do not include connectors. See pricing for details.
Open Extensions > Flookup Data Wrangler > Data Connectors and choose Airtable.
Before You Start
The first pull takes a couple of minutes once these four things are in place.
- A pass that includes connectors, because the 1-Month Pass and the trial do not.
- Access to the base you want, either as its owner or as a collaborator with read permission.
- A personal access token with the scopes below, granted to that base and no others.
- An empty tab named Flookup Staging. The connector creates it on the first pull, but a blank spreadsheet is easier to test in.
| Scope | What it unlocks |
|---|---|
| schema.bases:read | Lists the bases and tables the token can see, which is what Load bases uses. |
| data.records:read | Reads records for the pull itself. |
| data.records:write | Sends changed fields back. Skip it if the sheet only reads. |
Grant the token access to named bases rather than every base in the workspace. A token that reaches one base cannot leak a different one if it is copied into the wrong spreadsheet.
Create the Token
- In Airtable, open your account menu and choose Developer hub, then Personal access tokens.
- Create a token with the data.records:read and schema.bases:read scopes.
- Add data.records:write if you want write-back, and grant the token access to the bases you need.
- Copy the token. Airtable shows it once.
Without schema.bases:read the sidebar cannot list your bases, even though a direct pull might still work.
Connect Airtable
- Paste the token into the Airtable card and click Save token.
- Click Load bases and choose a base.
- Choose a table. Optionally name a view to limit which records are pulled.
The token is stored in your Apps Script user properties and is never shown back in the sidebar. Use Clear to remove it.
Pull Records
Click Pull to staging. Flookup clears the staging sheet and writes the field names as a bold header row, then the records.
- Pages are fetched 100 records at a time, with a short pause to stay inside Airtable's 5 requests per second limit.
- A pull stops at 5,000 rows and says so. Narrow the view if you need a smaller set.
- Linked records and arrays are flattened into comma-separated text so every cell is usable. Edit those fields in Airtable, not in the staging sheet.
- A hidden _flookup_record_id column keeps the source id for write-back. Do not edit or delete it.
Check the pull before you clean it. The header row should list the fields you expected, the row count should match the view you chose, and the id column should be present if you plan to write back. A field missing from the header is a sign the token cannot see it, not that the record is empty.
Write Changes Back
- Edit the staging sheet, or clean it with Standard Data Cleaning.
- In the Airtable card, click Preview changes.
- Review the new, changed and unchanged counts, plus the sample rows.
- Click Apply changes.
Only changed fields are sent, in batches of ten. New rows without a record id are created. Rows that exist in Airtable but not in the staging sheet are left alone: write-back never deletes. A run applies at most 500 changes.
Records are matched by the stored id, so a row that has moved out of the selected view is updated rather than created again. Formula, rollup, count, lookup, created-time, auto-number and button fields are read-only in Airtable, so write-back skips them even when a cell changes.
A record deleted in Airtable while its row is still in the staging sheet is created again on write-back, because the staging row no longer matches anything in the source. Remove the row from staging when the record should stay deleted.
Attachment and linked-record columns arrive as flattened text. Treat them as read-only in staging: a changed cell is sent back as text, and Airtable may reject it or create new linked records.
Airtable writes in batches with no transaction across them. If a later batch fails, the earlier batches stay written, so re-preview after any error instead of assuming nothing changed.
Each applied change is appended to a Flookup Changes sheet with the timestamp, table, record id, field, before value and after value. A failed run logs the batches that were written before the error.
Apply is tied to the preview you just saw. If the staging sheet or the source changes in between, the write is refused and you preview again. A preview stays valid for 15 minutes and can be used once.
Before the first real write-back, prove the round trip on a view that holds a handful of records.
- Pull that view, then change one field in one row.
- Preview the changes and confirm the counts read one changed row and nothing new.
- Apply, then open the record in Airtable to confirm the field and nothing else moved.
A test this small catches the two failures that matter: a write aimed at the wrong table, and a flattened column sent back as text.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Load bases returns 403 | The token lacks schema.bases:read, or the base is not in the token's access list. |
| Airtable returned HTTP 429 | The base hit 5 requests per second. Flookup retries twice with a pause; wait a minute and try again. |
| A formula or rollup cell will not save | Airtable calculates those fields. The connector skips them, so edit the field they depend on instead, or change the formula in Airtable. |
| Record ids are missing | The staging sheet predates this version. Pull again before previewing write-back. |
| Preview shows every row as new | The staging sheet was copied from another spreadsheet, so the hidden id column was lost. Pull again. |
Frequently Asked Questions
Which Airtable token scopes does Flookup need?
Create a personal access token with data.records:read and schema.bases:read. Add data.records:write only if you want write-back.
Does Airtable write-back replace the whole record?
No. Only the fields that differ from the source are sent, and rows missing from the staging sheet are never deleted. A record deleted in Airtable while its row is still staged is created again, so remove the row from staging when the record should stay deleted.
Why does the token fail on Load bases?
The token is missing schema.bases:read, or it has not been granted access to that base. Edit the token's access list in Airtable.
Can I edit linked-record or attachment columns in the staging sheet?
Treat them as read-only. Those columns arrive as flattened text, and a changed cell is sent back as text, which Airtable may reject or turn into new linked records.
What happens to Airtable record ids?
Each pull adds a hidden _flookup_record_id column. Write-back uses it to update the right record instead of creating a duplicate. Do not delete or edit that column.