Airtable Connector for Google Sheets
Introduction
The Airtable connector pulls a base and table into Flookup Staging, so you can deduplicate, standardise or match the records with the same tools you use on any sheet.
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.
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.
- A hidden _flookup_record_id column keeps the source id for write-back. Do not edit or delete it.
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.
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. |
| 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.
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.
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.
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.