Airtable
Overview
Airtable combines the ease of a spreadsheet with the power of a database. Connect with Airtable to build custom internal tools to automatically updating data, sync information across apps, and visualize your Airtable data in Superblocks.
Setting up Airtable
Create an access token
To get started you'll need a Airtable access token. To create a token:
- Log in to Airtable
- Navigate to Developer hub → Personal access tokens
- Click Create new token
- Name your token and configure scopes & access based on the data you want to access
- Click Create token
- Copy the API key to configure your integration's connection
Learn more about Airtable API Authentication
Add integration
Once you have an access token, you're ready to set up your Superblocks integration.
- In the web app, navigate to the Integrations page
- Click on the Airtable tile
- Name the integration
- Paste your credentials into the relevant fields
- Optionally, add more configurations to set credentials for different environments
- Click Create
Airtable connected Now you can use Airtable in any Application, Workflow, or Scheduled Job.
Use Airtable in APIs
Once your Airtable integration is created, you can start calling Airtable actions in Superblocks APIs.
Airtable actions are REST requests. To learn more about REST requests in Superblocks, see the Building REST requests guide.
Supported actions
List bases
Returns the list of bases the API key can access in the order they appear on the user's home screen, 1000 bases at a time. If there is another page to request, pass the offset as a URL query parameter. (e.g. `?offset=itr23sEjsdfEr3282/appSW9R5uCNmRmfl6`)Create base
Creates a new base with the provided tables and returns the schema for the newly created base. Refer to field types for supported field types, the write format for field options, and other specifics for certain field types. Supported field types have a write format shown. At least one table and field must be specified. The first field in the fields array will be used as the table's primary field and must be a supported primary field type. Fields must have case-insensitive unique names within the table. A default grid view will be created with all fields visible for each provided table.Get base schema
Returns the schema of the tables in the specified base.Create table
Creates a new table and returns the schema for the newly created table. Refer to [field types](/api/model/field-type) for supported field types, the write format for field options, and other specifics for certain field types. Supported field types have a write format shown. At least one field must be specified. The first field in the fields array will be used as the table's primary field and must be a supported primary field type. Fields must have case-insensitive unique names within the table. A default grid view will be created with all fields visible.Update table
Updates the name and/or description of a table. At least one of name or description must be specified.List records
List records in a table. Note that table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. The server returns one page of records at a time. Each page will contain **pageSize** records, which is 100 by default. If there are more records, the response will contain an **offset**. To fetch the next page of records, include **offset** in the next request's parameters. Pagination will stop when you've reached the end of your table. If the **maxRecords** parameter is passed, pagination will stop once you've reached this maximum. Returned records do not include any fields with "empty" values, e.g. **""**, **[]**, or **false**. You can filter, sort, and format the results with query parameters. Note that these parameters need to be URL encoded. You can use our [API URL encoder tool](https://codepen.io/airtable/pen/MeXqOg) to help with this. If you are using a helper library like [Airtable.js](https://github.com/Airtable/airtable.js), these parameters will be automatically encoded. **Note** Airtable's API only accepts request with a URL shorter than 16,000 characters. Encoded formulas may cause your requests to exceed this limit. To fix this issue you can instead make a POST request to `/v0/{baseId}/{tableIdOrName}/listRecords` while passing the parameters within the body of the request instead of the query parameters.Create records
Creates multiple records. Note that table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. Your request body should include an array of up to 10 record objects. Each of these objects should have one key whose value is an inner object containing your record's cell values, keyed by either field name or field id. Returns a unique array of the newly created record ids if the call succeeds. You can also include a single record object at the top level.Update multiple records
Updates up to 10 records, or upserts them when `performUpsert` is set (see below). The URL path accepts both table names and table IDs. We recommend using table IDs so you don't need to modify your API request when your table name changes. A `PATCH` request will only update the fields included in the request. Fields not included in the request will be unchanged. A `PUT` request will perform a destructive update and clear all unincluded cell values. ### Upserts Set the `performUpsert` property in your request to enable upsert behavior. When upserting is enabled, the `id` property of records becomes optional. Records that do not include `id` will use the fields chosen by [`fieldsToMergeOn`](/api/update-multiple-records#request-performupsert-fieldstomergeon) as an external ID to match with existing records. * If zero matches are found, a new record will be created. * If one match is found, that record will be updated. * If multiple matches are found, the request will fail. Records that include `id` will ignore `fieldsToMergeOn` and behave as normal updates. If no record with the given `id` exists, the request will fail and will not create a new record. The API response for upsert requests will additionally include `updatedRecords` and `createdRecords` arrays, indicating which records in the `records` array already existed and were updated, or did not exist and were created, respectively. Airtable reserves the right to throttle upsert requests differently from the [standard rate limit throttling policy](https://airtable.com/developers/web/api/rate-limits). ### Typecasting Set the `typecast` parameter to `true` to enable typecasting. When typecasting is enabled, Airtable will try to convert string values in a record's `fields` object to the appropriate cell value. This conversion is only performed on a best-effort basis. Typecasting is disabled by default to ensure your data's integrity, but it may be helpful when integrating with third-party services.Delete multiple records
Deletes records given an array of record idsGet record
Retrieve a single record. Any "empty" fields (e.g. **""**, **[]**, or **false**) in the record will not be returned.Update record
Updates a single record. Table names and table ids can be used interchangeably. We recommend using table IDs so you don't need to modify your API request when your table name changes. A **PATCH** request will only update the fields you specify, leaving the rest as they were. A **PUT** request will perform a destructive update and clear all unspecified cell values. Your request body should include an array of up to 10 record objects. Each of these objects should have an **id** property representing the record ID and a **fields** property which contains all of your record's cell values by field name or field id for all of your record's cell values by field name. Automatic data conversion for update actions can be enabled via **typecast** parameter. The Airtable API will perform best-effort automatic data conversion from string values if the **typecast** parameter is passed in. Automatic conversion is disabled by default to ensure data integrity, but it may be helpful for integrating with 3rd party data sources.Delete record
Deletes a single recordSync CSV data
Syncs raw CSV data into a Sync API table. You must first set up a sync from a base (instructions in this [support article](https://support.airtable.com/docs/airtable-sync-integration-api-endpoint)). The **apiEndpointSyncId** in the path parameters can be found in the setup flow when creating a new Sync API table, or from the synced table settings. The CSV data can contain up to 10k rows, 500 columns, and the HTTP request's size is limited to 2 MB. There is a rate limit of 1 request, per 10 minutes, per base for this endpoint.Create field
Creates a new column and returns the schema for the newly created column. Refer to field types for supported [field types](/api/model/field-type), the write format for field options, and other specifics for certain field types. Supported field types have a write format shown.Update field
Updates the name and/or description of a field. At least one of name or description must be specified.Example usage
Applications
Airtable's API returns embedded fields for each record. To flatten the response so each field is a top level key to be used as a table column header in Superblocks, add the following JavaScript step after a call to List records
:
return <AIRTABLE_STEP_NAME>.output.records.map(item => item.fields);
See our step-by-step guide for fetching paginated records from Airtable.
With the Airtable data properly formatted, we can now visualize it in a table alongside other information and components like dropdowns, charts, and slideouts.
Generic HTTP Request
Every SaaS integration in Superblocks comes with a built in Generic HTTP Request Action. This is a powerful action you can use to call Airtable API endpoints not in the Superblocks supported actions.
To use this action simply add the method, path, required query parameters, and body for the desired endpoint.
Learn more about REST requests in Superblocks in our Building REST requests guide.
Generic HTTP Requests use the authentication set up and base URL you've configured for your integration, making it an easy for your team to extend Superblocks Integrations to meet their needs.