Airtable API key deprecation notice
  • 31 Jan 2024
  • 8 Minuten zu lesen
  • Dunkel
  • pdf

Airtable API key deprecation notice

  • Dunkel
  • pdf

The content is currently unavailable in German. You are viewing the default English version.
Article Summary

This notice was originally published January 2023. As of February 1st, 2024, the deprecation period for Airtable API keys has ended. Users of Airtable API keys must migrate to the new authentication methods to continue using Airtable's API.


If you've added your Airtable API key to 3rd party tools like Zapier, Make, etc. Please reference the below table for a summary of what may be impacted. As mentioned in the How can I find what is using my API key section, Airtable is NOT able to identify the particular bases that are using an API key. Review that section for more details about where you may have used your API key.


Use case


Personal Access Tokens

Individual use - Scripting, API calls

OAuth for integrations

Connecting Airtable with third-party integrations

API key deprecation details and timeline


As this is a major change to the Airtable API, the API Key deprecation period will last for 12 months and end on Feb 1, 2024

  • After that date, API Keys will no longer be able to access the Airtable API. 

  • Webhooks created with User API keys will not expire, but can no longer be created.

  • We recommend that all users migrate to Personal Access Tokens for individual use and OAuth for third-party integrations moving forward.


  • January 2023: Initial community forum announcement and emails

  • Mid-February 2023: We will email API key owners with recent API key usage to directly inform them of the changes

  • August 1st, 2023: Users can no longer create new API keys

  • February 1st, 2024: Existing API keys can no longer be used to access the Airtable API

How can I find what is using my API key?

Unlike our new authentication methods, Airtable is not able to determine what is using your API key or who you may have shared your API key with in the past. This is a benefit of using OAuth for integrations - you will be easily able to view and manage your authorized OAuth integrations, and any activity coming from integrations will be attributed to the specific integration. Developers can also create multiple personal access tokens for different API integrations, rather than having one API key used by multiple integrations.

To find out what is using your API key, we recommend checking the following:

  1. Custom integrations set up by you or developers on your team

  2. Data connections and scripts that use your Airtable data (e.g. Tableau web data connector, Power BI & Power Query)

  3. Third-party integrations you have connected your Airtable account to (e.g. Zapier and Make)
    Note: We are working with third-party integrations to migrate to using OAuth for integrations. No action is required on your part until they complete the migration, after which you can stop using your API key and use OAuth to connect instead. 

  4. Third-party marketplace extensions that requested your Airtable API key (e.g. Data Fetcher)

  5. Airtable plugins for other apps (e.g. Airtable Data Sync to Hubspot)

Custom integrations & data connections should be updated to use personal access tokens, while third-party integrations, extensions and plugins require you to re-authorize using OAuth. If you are unsure how to set up OAuth for a specific partner or OAuth is not currently available for that partner, we recommend you contact their team for details on when it will be available. Many partners have already implemented OAuth - here are guides written by Zapier, Make, and Fivetran on how to migrate your usage.

  • Note that other Airtable functionality such as sync integrations and automations are not impacted by this change, as they do not use Airtable API keys.

  • If you are an Airtable Enterprise Scale customer, you can also contact your account representative to request further support regarding this migration. 

Automatic Migration of Zapier Connections

On September 25th, Zapier will begin automatically migrating Airtable legacy user API Keys into OAuth authorizations. This change is part of the broader process of Airtable API key deprecation, moving towards a more secure OAuth system.

This automatic migration means that Zapier will convert Zapier connections that use existing Airtable API Keys into OAuth authorizations without requiring any input from you. The Airtable API Key will not be deleted or reset during this conversion process and will still function in other integrations where it might be in use.

How to check on the Zapier connections that were migrated

To check the status of your migrated connections in Zapier, you can navigate to your Zapier dashboard and click on "Test" next to the account. Zapier will attempt to make a connection with the associated Airtable integration. If the connection is successful, you'll see a message like "Success! Your account is working properly." If there's an issue, Zapier should provide an error message detailing the problem. Please refer to Zapier’s instructions to Test your app connection for failures.

To check your connected accounts in Airtable, click on your Profile picture in the top-right corner of Airtable, click “Integrations”, then "Third-party integrations”. From here, you can view integrations that have already been converted to OAuth authorizations, revoke access, or limit access to specific bases and workspaces: see this support article for more details

Instructions for Enterprise Scale customers

For Enterprise Scale customers, after the migration, Zapier will be controlled under the Disable API access for third-party integrations setting in your enterprise’s OAuth settings.

This setting applies to OAuth integrations, not legacy user API keys. If your enterprise has blocked API access for third-party integrations and has not added Zapier to the Third-party integration allowlist, you might start seeing failures. The API error will be OAUTH_INTEGRATION_NOT_ALLOWED_FOR_ENTERPRISE, and the message will be "This OAuth integration is restricted by the enterprise that the authorized user belongs to. The authorized user needs to request their enterprise admin to allow this integration."

To prevent this, as an Airtable Admin, you can allowlist Zapier ahead of time. To do this:

  1. Navigate to Admin Panel and click on Settings

  2. Then click on Integrations & development

  3. Scroll down to Block API access for all third-party integrations. If this setting is toggled on and you wish to allow Zapier, add the Zapier integration to the Third party integration allowlist by providing the Client ID b8128479-33a9-493c-8f95-2e6309c37c99.

As a non-Admin user, you can view whether or not your Zapier integration is being blocked by this Enterprise Admin setting by clicking on your Profile picture in Airtable -> Integrations -> Third party integrations. If the integration is authorized with a Service Account, you'll need to ask an Enterprise Admin to view the Users page of the Admin panel to view the Service Account’s OAuth Integrations.

Please note that these types of connections using legacy user API keys would be expected to stop working regardless of when the legacy API keys are fully deprecated on February 1st, 2024. Zapier has been sending advance notice emails about this migration


Why is Airtable doing this?

Personal Access Tokens and OAuth provide a higher standard for security over API Keys, which were the predecessors that provided “all-or-nothing” access over everything that an Airtable user account could see or do. These new methods have more granular control of resources and scopes and allow you to extend Airtable, all while ensuring the highest grade of security.

Who is affected by the API key deprecation?

Anyone using API Keys will be affected by this change. This could be you as an end-user, or some other end-user for whom you have built an existing integration upon the Airtable API.

How will this change impact me if I have previously utilized API keys to connect third-party services with Airtable?

Third-party services need to migrate to using OAuth for authentication - many partners are already working on this.

We recommend that you contact the third-party services currently supporting API keys and request that they add OAuth support before our deprecation period ends. As a reminder, API keys can still be utilized until February 2024. So, until then, no direct action is needed to ensure that your existing integrations will work related to this change.

How do I start using OAuth?

  • As a user - After the third-party service has migrated to using OAuth, then you can re-connect with Airtable from the third-party website/app/etc. Here are guides written by Zapier, Make, and Fivetran on how to migrate your usage

  • As a developer - Please refer to this guide on how to implement OAuth with Airtable.

How will this change impact me if I have previously utilized API keys to connect or build API integrations with Airtable?

You will need to update your API integrations to use personal access tokens instead of API keys before February 2024.

How do I start using personal access tokens?

Personal access tokens can be created at After a PAT has been created, you can use it to authorize your API requests, replacing the way that API keys were used in the past. You can find more information in this guide.

If you are an enterprise admin, you can also create a personal access token for a service account from the Admin Panel.


If you were previously passing your API key as a query parameter, you will also need to update your API requests to pass the personal access token via the HTTP authorization bearer header instead. More information is available here.

What can my personal access tokens access?

Unlike legacy API keys, which have the same access as your Airtable account, you can limit and configure the access of your personal access tokens. You can do this by selecting the scopes (what endpoints the token can use) and access/resources (which bases and workspaces the token can access) when creating or updating a token. 

Regardless of the scopes and access a user selects for their token, the token will only be able to perform actions that the user themselves is allowed to do. For example, to create a new field in a base via the API, the user must be a Creator collaborator in the base, plus the token must have the schema.bases:write scope and the base added as a resource. 

For more information about how scopes and access work, see the Authentication developer reference. For more information about configuring your token's access, refer to the personal access tokens guide.

What do I need to do?

We understand this is a big change, so we’ll be sending out more actionable details in the coming weeks to make this transition as smooth as possible. Keep a lookout for an email from soon (Mid-February 2023).

War dieser Artikel hilfreich?