Can you share a link where this is stated? I see that this page states that user IDs can be retrived via the Enterprise admin, but it doesn’t say that it is the only way.

Two other ways of getting user IDs are via automations with a collaborator field, or via scripting.

There are at least 5 (and possibly more) ways of getting User IDs:

1. ALL USERS: By using Airtable automations or external automations.
2. ALL USERS: By writing Javascripts.
3. ALL USERS: By using the API to read a collaborator field.
4. ENTERPRISE USERS: By using the Get Collaborator API functions.
5. ENTERPRISE USERS: By exporting the Admin Panel.

By omitting any reference to any other ways of getting User IDs, it strongly implies that it is the only way.

So excited to see the metadata API see the light!!!

I have a question around the OAuth flow: is code_challenge_method required when doing the POST to https://airtable.com/oauth2/v1/token?

If it is, then it seems off the spec, is it possible to remove it as required?

I am using a third party for the integration which supports PKCE but they follow the spec and don’t send it and will be difficult to convince them to add it as it is off the spec.

As an example, I took a look at a major OAuth2 library (PassportJS) and it only sends the method in the authorization step, and only the verifier during token exchange.

is code_challenge_method required when doing the POST to https://airtable.com/oauth2/v1/token?

It should not be, thankfully I believe this is just an error in our docs (a fix is now incoming). Spec compliance is generally important to us so please reach out if you find similar errors.

Thanks for the reply @Will_Powelson, this is the request with all the info, the only thing that comes to mind why it is failing is that code_challenge_method is required, can’t think of anything else.

[Album] imgur.com

Hi Lean, I can confirm that myself and other users are able to create tokens without code_challenge_method.

While I can’t diagnose your problem without access to your client_id (not that I’m asking you to post it publicly) a few possibilities come to mind:

1. it is possible you are running into a bug I am currently chasing down.
2. The redirect_uri you’re providing does not exactly match the one used in the authorization request
3. Your code_verifier may be incorrect
4. You may have accidentally altered the code you received
5. You are waiting 10 minutes or more after authorizing to make this request

Hey,

Firstly, awesome work on all these changes, especially webhooks!

Some feedback on the OAuth consent screen: it’s very easy to miss the small ‘Add a base’ button. I feel like a lot of users will breeze past it and just click ‘Authorize’.

It that case, does the access token get access to all their workspaces or none of them? I’m assuming it’s none, in which case I think that button needs to be much more prominent.

Here’s the Webflow OAuth consent screen as a comparison - it’s not perfect but the list of workspaces is much clearer.

Thanks for confirming that it is not required Will, I have sent you a private message with the client id to see if you can verify if the problem is related with the bug, I can confirm that 2, 4 and 5 are not the problem and will double check 3, but the same logic is working fine with other services so it is probably not either.

Hi @Ruchika_Abbi1 thanks for your question… Old apps will continue working with api keys (no need to change in there… we will check if we can allow users to replace old keys with tokens) for the new Apps we will be using OAuth as it’s way better in many ways… We are now in evaluation step and will start implementing soon.

–Artur

Agree with Andy, It’s very easy to miss. and if without it there is no access it should at least be required… or way bigger :slightly_smiling_face:

Hi! A quick question about the new PAT tokens (RAS syndrome :frowning_face: ). Do they expire after a set time? If not, what are the conditions for them to stop working and require regeneration? Are there plans in the future to implement a set expiration date?

Also, slightly unrelated, do API keys expire?

Congrats @SeanKeenan! So excited to see these developments!

When the API key is deprected will I lose access to all my third party integrations?
Third party apps like Airtable just ask for a Web API key and don’t accept the new tokens.

@LeanZubrezki

(I also sent you a DM with more info) After some investigation I believe the issue is actually that our example repo had insufficient error-handling and was making requests for a token after the /authorization request had been denied.

I’ve updated the example repo and will work to improve the error handling here from our servers.

@Andy_Cloke
Noted! There is an update coming soon that will require users to add at least one base or workspace when it is required for the integration to work.

We don’t know yet when API keys will be depreciated, but we will have a warning of at least a year. That should give you enough time to update your third party integrations with new connections.

Although some third party apps do not allow you to change an existing token, they usually allow creating a new connection with a new token, and you can switch the integration to the new connection.

If you are concerned that a specific 3rd party service does not allow switching connections, you can contact them and let them know that they should implement that feature. They will have at least a year to do so.

Just replied and sent a quick Loom showing the problem, I am not actually using the example code so I think there is something else going on :frowning:

Is there any UI for viewing/deleting base webhooks? I might have missed it.

Looks like OAuth apps can’t list/delete webhooks created by other apps (which is great and how it should be)

Personal access tokens can list/delete all webhooks so I could hack something together if necessary.

@ScottWorld

There are at least 5 (and possibly more) ways of getting User IDs:

1. ALL USERS: By using Airtable automations or external automations.
2. ALL USERS: By writing Javascripts.
3. ALL USERS: By using the API to read a collaborator field.
4. ENTERPRISE USERS: By using the Get Collaborator API functions.
5. ENTERPRISE USERS: By exporting the Admin Panel.

@kuovonne

but it doesn’t say that it is the only way.

By omitting any reference to any other ways of getting User IDs, it strongly implies that it is the only way.

---

That's a good point, I've updated the documentation to make this a bit clearer (expect the update to be live in about a week) highlighting that you can also get all of the UserId's via the scripting extension and automations.

While it's true you can get UserId's via other surfaces (like the collaborator field), these don't provide all of the user id's in the base. Most of the time you shouldn't need additional information because the response also includes the User Mentioned object, which includes the relevant information about the user, like the display name and email address (the same information included in the collaborator field object). The one exception is when making comments, in which case getting the list of available users from other surfaces can be valuable.

@SeanKeenan@Will_Powelsoncurrently we can't programatically create tables with fields like formula or lookup any idea when those would be supported ? without them it's very limited. Thanks!

@SeanKeenan is there an endpoint to pass the token and retrieve the auth scopes ? something like token info that googlesheet and others have ?

@Sean_Keenan we are getting the following error message:

You have reached the maximum access authorizations for this integration. You cannot authorize this integration again until you revoke at least one of the authorizations

What does it mean ? what  are the limitations ?

Can't we our OAuth integration to be used by 1000s of users ?

Hi, this is good news, also is there a plan for implementing an endpoint to create snapshots? 

Hi! I'm Emma, an engineer on the API team at Airtable who worked on this project. Going to answer a few related questions about personal access tokens vs OAuth vs API keys in this post:

@kuovonne : I find this support page about personal access tokens to be confusing. Here are the first two paragraphs.

Note: Kuovonne and I also chatted about this topic elsewhere, I'm posting a summary of our discussion here for public reference.

Today, the only way to set up third-party integrations is to give them your API key. Starting from this public beta, our recommendation is for third party integrations to use OAuth (i.e. they should not ask users to give them a personal access token or API key). This is for better security as well as a better user experience. OAuth gives the same benefits as personal access tokens in regards to having tokens with limited scope (declared by the developer) and limited base/workspace access that the user can control, plus additional security benefits for the user since they never have to copy and paste tokens manually, and because OAuth tokens expire and need to be refreshed (vs personal access tokens which never expire).

On the other hand, personal access tokens are for personal use - we describe this as “yourself, your client or for your company”.

This recommendation is documented on the personal access tokens guide and on the Authorization reference:

If you are building an integration that allow other users to grant your integration access to Airtable, you should instead create an OAuth integration.

This recommendation applies to both new integrations being built as well as existing integrations that use API keys. We've notified all current metadata API partners about these betas as well as the upcoming, planned deprecation of API keys, and we'll continue to be in touch with those partners as further details about the deprecation timeline are announced. We do know that migrating to OAuth takes time and work - the deprecation period for API keys will be at least 12 months, existing keys will continue to work through that time and so partners have that much time to migrate.

@Ruchika_Abbi1 : How does this impact platforms like Softr / StackerHQ? Does this mean they should be using tokens to connect to Airtable? Currently I create an “API user” account and then use the API keys for this account to connect to other platforms or for low code integrations through JS. Does it mean that going forward I should create a token and access the API’s through this token? Will there be a charge to these tokens?

@Artur_Mkrtchyan : Hi @Ruchika_Abbi1 thanks for your question… Old apps will continue working with api keys (no need to change in there… we will check if we can allow users to replace old keys with tokens) for the new Apps we will be using OAuth as it’s way better in many ways… We are now in evaluation step and will start implementing soon.

Thanks Artur! Adding on to Artur's response - yes, we are recommending that platforms like Softr / StackerHQ migrate to using OAuth, more detail in my reply above to Kuovonne's question.

We also see the more recent questions about OAuth implementation in this thread and we're checking with the team on getting answers for those!

@Ava_Li : Hi! A quick question about the new PAT tokens (RAS syndrome ☹ ). Do they expire after a set time? If not, what are the conditions for them to stop working and require regeneration? Are there plans in the future to implement a set expiration date? Also, slightly unrelated, do API keys expire?

Hi @Ava_Li ! Personal access tokens do not expire after a set time. You can delete them or regenerate them manually from /create/tokens. Implementing a set expiration date is something the team has discussed but is not currently on our roadmap.

API keys do not expire, but can be similarly cleared or regenerated from /account.

---

@Kamille_Parks11: Is there any thought on adding the ability to create new Views via the Web API (or Scripting/Blocks APIs)?

@Ambroise_Dhenai: Would it be possible to add to the Metadata API a read on Automations? So as to be able to extract the configuration of an automation (especially for documentation purposes, Changelog, etc.). Thanks !

@Artur_Mkrtchya1: currently we can't programatically create tables with fields like formula or lookup any idea when those would be supported ? without them it's very limited. Thanks!

@goksan: Is there any UI for viewing/deleting base webhooks? I might have missed it.

Thanks everyone for asking about these potential capabilities! These features are not currently on our roadmap.

Some are quite nontrivial to add: for example, when using airtable.com on the browser, views can have very complex conditions, formulas are checked for syntactic validity, and automations are even more complex, so we don't have immediate plans to expose these via the web API.

For exposing a UI to view/delete webhooks, since they're primarily developer-facing right now, we don't have plans to expose them via a UI.

The above being said, if you can share more details about what use cases you have in mind that can be unlocked by them, it would be helpful to inform our future plans!