New API capabilities now in GA and upcoming API keys deprecation period

[Fred_Zhao]

Hiya everybody,

For those I haven’t met, I’m Fred, an Engineering Manager here at Airtable.

Today our team is announcing the General Availability of many new API features to make our API Authentication more secure and reliable, as well as open up new API capabilities. These include:

• New authentication methods and endpoints that are now in general availability
• OAuth integrations and Personal Access Tokens for authentication
• Metadata API, comments API, and webhook API, available when using these two authentication methods
• New change since public beta: a sync integration that accepts CSV-formatted data through Airtable's Web API
• Check our changelog for all the details
• We’ll also be hosting an AMA ("Ask Me Anything") on Thursday, January 26th with some of the developers on our team to chat through all the latest API updates. You can find more details here

—

Additional upcoming changes to the API experience

With that, we are now announcing the beginning of the deprecation period for API Keys in favor of the two new API Authentication methods: Personal Access Tokens for individual use and OAuth for Integrations. Both new methods have more granular control of resources and scopes, and enable both developers and end-users to extend Airtable while ensuring the highest grade of security.

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 which API Keys will no longer be able to access the Airtable API. Related to this, webhooks created by API Keys in enterprise bases will also expire at the end of that period. We recommend all users to migrate to Personal Access Tokens for individual use and OAuth for third-party integrations moving forward.

Why are we doing this?

Personal Access Tokens and OAuth provide a higher standard for security over API Keys, which were the predecessor 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 while ensuring the highest grade of security.

Who is affected by this 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.

What do I need to do?

We understand this is a big change, so we’ll be sharing more details in the coming weeks to make this transition as smooth as possible: intermediate deprecation milestones, and more actionable details. The support article on API Keys will also be updated over time, so feel free to bookmark it.

While there are no immediate actions you need to take right now as we enter this deprecation period, remember that time flies! So we recommend all users begin migrating away from API Keys.

As always, you can learn more about our APIs from our developer docs. If you have any questions, don’t hesitate to ask here.

Fred, on behalf of the Airtable Team

[Karlstens]

This is most excellent work, something that we’ve all been waiting for. Thank you!🥳

[Nathan_Heironim]

If API KEYS are expiring, what does that mean for those of us using third-party services like Softr, Glide Apps, Stacker, etc? 

Personally, I'd appreciate hearing from anyone in the community who has experience creating OAUTH tokens for Softr?  Currently, I cannot seem to make sense of how to link Airtable data to Softr with any other method than API KEY.

[kuovonne]

What is the recommendation for dealing with third-party integrations that do not support OAuth? Should we keep using API keys until the third party provides OAuth support? Or may we switch those integrations to Personal Access Tokens while we wait for the third party to make the necessary change to support OAuth?

[StevenL]

Great news. The better security and more fine-grained permissions-control is appreciated.

What is the timeline or process for other web apps leveraging the new API features?

Make.com, for example, works well with the new personal access tokens. Zapier.com, on the other hand, does not work with these but needs the old API key in order to work.

[Emma_Yeap]

Hello! I'm Emma, an engineer on the API team at Airtable who worked on this project. Thanks for the thoughtful questions! Since they are all related to third-party services / integrations / web apps so far, I'll reply to them together in this post:

@Nathan_Heironim If API KEYS are expiring, what does that mean for those of us using third-party services like Softr, Glide Apps, Stacker, etc? 

Hi Nathan - you would need to wait for those third-party services to implement OAuth on their side first, after which you would be able to use OAuth from their website/app/etc to authorize access to your Airtable account.

We'll be including instructions for what to do in this scenario in our upcoming additional communications about the deprecation (i.e. what this means for you if are an end-user of a third party service that has your API key).

Our recommendation is for all third-party services to migrate from using API keys to using OAuth before API keys are deprecated. When these features were in beta, we already let all current metadata API partners know about OAuth and the planned deprecation of API keys. We will be contacting them again in the coming weeks letting them know about the GA and recommending that they migrate to OAuth.

Many top partners are already working on migrating to OAuth, including Zapier. For the specific services you mentioned, we don't have any information on their timelines/plans for migrating away from API keys - we recommend contacting them directly if you have questions or concerns.This forum post has more details on this topic, in response to a question Kuovonne asked during public beta: https://community.airtable.com/t5/announcements/new-beta-new-api-authentication-methods-endpoints-an...

@kuovonne What is the recommendation for dealing with third-party integrations that do not support OAuth? Should we keep using API keys until the third party provides OAuth support? Or may we switch those integrations to Personal Access Tokens while we wait for the third party to make the necessary change to support OAuth?

Hello (again) Kuovonne!

Yes, it is OK to keep using API keys until the third party provides OAuth support.

For developers of integrations, our recommendation is to migrate directly to supporting OAuth instead of supporting personal access keys and then eventually OAuth. We do know this requires more upfront work, but it's our recommendation for a better user experience (e.g. avoid needing to ask users to input a PAT, and then later re-authorize via OAuth and for the user to manually delete the PAT).

However, for users of integrations (which I believe your question here is about) our recommendation is less strong. As we've chatted about before, while OAuth is ideal from a security perspective for third-party integrations, using a PAT also gives you some of those new security benefits. So it's up to you if you want to get those benefits sooner at the cost of needing to delete the PAT/re-authorize via OAuth later.

One note: because personal access tokens and API keys have different formats, services that validate that the key matches the current format would not be able to accept PATs "out of the box" and so you may not be able to switch. (e.g. what StevenL mentions below about Zapier not working with personal access tokens)

@StevenL What is the timeline or process for other web apps leveraging the new API features?

Make.com, for example, works well with the new personal access tokens. Zapier.com, on the other hand, does not work with these but needs the old API key in order to work.

Hi Steven! I believe my reply to Nathan above covers your question - while we have informed partners about the new features & upcoming deprecation of API keys, the exact timeline for migration is up to them. And, as mentioned above, we will be contacting them again soon to recommend they migrate to OAuth.

Many partners, including Zapier, are already working on migrating to OAuth. If you have questions about a specific web app, we recommend contacting them directly to inquire about their plans for migration.

[Olpy_Acaflo]

Hi @Fred_Zhao , nice to meet you here.

Hi @Emma_Yeap  , thank you for your comeback, you already helped us during Custom Block SDK early hours in 2020.

I hope CODA ( @LeanZubrezki ), MiniExtensions ( @Moe  ), webflow.io are following this thread.

Best regards to early hours Scripting Block & Custom Block DEV,

oLπ

[ScottWorld]

@Fred_Zhao and @Emma_Yeap:

100% of my Airtable consulting clients, and the vast majority of people that I am aware of in the different Airtable communities, have fully migrated away from Zapier to Make.com because Make is more affordable, more powerful, more customizable, more reliable, and more user-friendly than Zapier. They even have better tech support, too.

Have you alerted Make about these API changes, and will you be helping them to make the transition?

[Greg_F]

Fantastic news - this is extremely useful feature. 🎉 Thanks for hard work to ship those features!

[hjalli]

Congratulations on the launch! It was an honor and a privilege to work with you @Fred_Zhao and the broader Airtable team as these APIs were being developed. We at GRID have now launched a major upgrade to our Airtable integration, and we're super excited about the power it brings to both GRID and Airtable users.

For a taste, see:

• Live refresh (uses webhooks, 23 sec video)
• Airtable integration landing page, including a 1 min video on setup

[LeanZubrezki]

@Olpy_Acaflo thanks for the mention and YES, the Airtable Pack for Coda has already been upgraded to use OAuth2, just need to finish writing a message to all Pack users so they reconnect their accounts after the release of the new version 🙂