SheetDream
Search…
Airtable
Airtable fields and definitions:
Field Name
Description
Base Name
The name of your Airtable base. An Airtable base can be home to many different tables.
Table Name
The name of the table within your Airtable base you want to sync. Note that this is case sensitive.
View Name
The view name you'd like to extract data from. Generally you'll want the default view that Airtable automatically creates for you (typically called "Grid view").
Allow SheetDream To Update This Table
Enables the ability for SheetDream to synchronize any modifications from the API side (newly POSTed records, changes made via PUT/PATCH/DELETE) back to Airtable.
Write API ID Back To Table
In some instances, you may want SheetDream to write the API's resource ID for each particular record back to your table. If you check this, you can specify a field SheetDream should write this value to.
Active
Indicates whether synchronization should be enabled and active.
Airtable API Key
Where do I find my Airtable API key?
Within your Airtable base that contains the table you want to create an API from: if you click on the Help link in the top right corner, it will expand a new panel on the right hand side of your screen. At the bottom of the panel you'll find an "Additional Resources" section, and within there you will see a link for "API documentation". Clicking on this will open a new tab directing you to documentation specifically tailored for this particular base. This documentation contains both the base name as well as your Airtable API key.
To expose my API key, I click "show API key" on the top right of the Airtable documentation. Then, if you head down to the Authentication section, in the curl tab you will see your API key here:
The string of characters to the right of "Bearer" is your API key. Copy & paste that value into the API Key field within SheetDream.
NOTE: do not share this API key with anyone else! Anyone who has this API key can make changes to your Airtable data.
Finding Your Base Name And Table Name
In your Airtable documentation in the Introduction section, there is a sentence that says:
"The ID of your base is app____"
This is your Base Name. Base Names start with the app prefix and contain a random assortment of characters to uniquely identify your base. This value should be copied & pasted into the Base Name field in SheetDream:
Next, you need to input the table name that you want to pull data from. It should match exactly (casing and everything) what you have in Airtable:
In our case above, it would be "tweets" exactly:
Specifying A View Name
Next, we have to select which View from Airtable we'll be synchronizing data from. By default, every new table within Airtable tends to get a default view called "Grid view", and that is what the default value is in SheetDream.
If you have changed the view's name within Airtable to something other than "Grid view", you will need to change that value here as well. Otherwise, you can keep it set to "Grid view" which will pull in all of the fields from your Airtable. Take note that this view name is case sensitive as well.
Finally, we make sure "Active" is checked and we click "Save Changes".
SheetDream will attempt to make a call out to the Airtable API to grab data about your table to verify that the connection details you've entered are valid. Assuming it connects successfully, it will present you with a message saying "Successfully updated configuration."
What is "Allow SheetDream To Update This Table"?
This setting allows the API that SheetDream creates for you to make changes to your Airtable. If you POST, PUT, or DELETE data on the SheetDream API you will see those changes reflect within your Airtable as well.
Data Merging Considerations
As with Google Sheets, unless you're running some sort of sophisticated data merging algorithm, when syncing data between multiple data stores, one of those data stores needs to be considered the source of truth.
When you hook SheetDream up to an Airtable and give it update capability, it becomes the source of truth for that particular dataset.
What this means is: if you were to make a modification to a specific row (either changing some columns, or deleting the row) on the Airtable side: but a user of your API happens to make a change to that exact same row at the same time, there's a possibility any changes you made will get overwritten by SheetDream.
This is a deliberate design consideration to ensure that you can give your users the best possible experience from the API side.
You should design your Airtable tables in a way to where SheetDream will be updating a table that you will only rarely ever touch. You can do this by splitting your tables in such a way that SheetDream will be making updates to one particular table, and you can then use Airtable's record linking and lookup field functionality to pull data from that table into the table you'll be actively working in.
SheetDream/Airtable Limitations
During your initial configuration of Airtable, when you start pushing data to Airtable via the API there may be slight inconsistency in update intervals on the Airtable side. What this means is that you may notice slightly longer delays for new data to appear in Airtable.
This occurs because SheetDream is still calibrating your table. More specifically, if you employ several formula fields in a table you have synced, SheetDream has to learn which fields it can push updates to and which ones it cannot.
Once calibration is complete, you should generally notice updates getting pushed to the Airtable side every 3 to 10 minutes.
If you would like data refresh times faster than 3-10 minutes, please contact us about running private servers on our Premium tier.
If you make an architectural change to a table that is synced to SheetDream (an architectural change would be changing a column's underlying type, or renaming a column) it is generally a good idea to click "Purge From Cache" on the Table Preview tab in SheetDream. If you don't, SheetDream may get confused about the type of the field it's looking at when it compares your newest data with the data it has in its cache. This could lead to some unforeseen consequences for your API, like certain records having a field represented as multiple types depending on the record in question (e.g. string and number), or some records having old column data.
When you link one record to another in Airtable, often times Airtable will ask you if you'd like to add what's called a Lookup field. This is a field that pulls a column from the linked table. When you do this, Airtable will traditionally name this field "Field (from OtherTable)". It's generally a good idea to get rid of the parenthesis from these fields. They can cause issues with scripts later on down the line: specifically being able to query your API (which is sensitive to '(' and ')' characters) or Handlebars.js issues.
Another important note is that generally speaking, it is a good idea to format dates in ISO UTC format on the Airtable side. This will help during the development process. Here are the configuration settings you're looking for:
Supported Field Types
The following table details SheetDream's support level for various types of fields in Airtable:
Field Type
Read/Write
Read Only
Not Supported (Avoid)
Single line of text
X
Long text
X
Attachment
X
Checkbox
X
Multiple select
X
Single select
X
Collaborator
X
Date
X
Phone number
X
Email
X
URL
X
Number
X
Currency
X
Percent
X
Duration
X
Rating
X
Formula
X
Count
X
Lookup
X
Most of the restrictions (with the exception of the Checkbox) are in a concerted effort to make SheetDream's APIs compatible with both Airtable and Google Sheets. Airtable has considerably more field types than Google Sheets and SheetDream needs to simplify to support both.
The Checkbox is a special case, in that Airtable's API does not treat Checkbox's as a boolean value like you would expect. It can lead to scenarios where records that have a field as unchecked don't contain the Checkbox's column at all, while records that have a field as checked do have the column. This can lead to confusing scenarios and inconsistency with what your API returns. It's for this reason our general recommendation is to avoid the Checkbox field in Airtable, and instead use a Single select of Yes/No or True/False in your apps.
Last modified 3mo ago