Enable creating an application that has it’s own api key
Allow it to perform actions on bases / tables granted access to
Example: an app to allow users to do things for a company…
20 users login to the app using 1 user’s key…
Now they all quickly hit the 5 requests per 1 second rule
Anddddd if the app performs crud, they are acting as the api key user.
oAuth application
Could just be a global “user model” with it’s own key.
And people can invite that application aka user to their bases.
I think that there are definitely quite a lot of use cases out there that would benefit from this.
I’d imagine that this is always going to be on the cards @dillingham, but I have to say that I think part of Airtable’s success with their API (and their API and docs, in my opinion, is perhaps some of the best on the planet for newbies) is you can get started with only a Bearer token.
The more apps do this, the higher their adoption will be, because the barrier to entry is significantly lower than having to configure oAuth.
That being said, I can imagine that having bearer only is blocking devs creating production apps based on Airtable at the moment - So I feel your pain.
@andywingrave apps don’t have one or the other. Many mainstream apps have both personal keys, oauth and oauth2. Github for example has both personal keys and the ability to create applications that people can authorize.
The biggest pain point for me is building an app for some users that aren’t Airtable users. So when a person installs the app for the company and gives their personal Airtable api key… all actions performed by external users are on behalf of the Airtable user who set it up. Would be better if it was by the application (my app) they authorized.
I think in terms of adoption that would only expand the kind of applications built using Airtable.
@andywingrave apps don’t have one or the other. Many mainstream apps have both personal keys, oauth and oauth2. Github for example has both personal keys and the ability to create applications that people can authorize.
The biggest pain point for me is building an app for some users that aren’t Airtable users. So when a person installs the app for the company and gives their personal Airtable api key… all actions performed by external users are on behalf of the Airtable user who set it up. Would be better if it was by the application (my app) they authorized.
I think in terms of adoption that would only expand the kind of applications built using Airtable.
Hey! Haha! Yes, I know apps don’t have one or the other :laughing: - I was just saying that this would have been an architectural and prioritization decision at some point, and I for one am glad they prioritised personal keys. I work with so many APIs where I need to build a whole app just to send a single request. It’s time-consuming as a developer, requires far more thought, and has little benefit unless actually building a purpose-built app.
(I was agreeing with you, and yet I was still corrected) - For a moment I forgot I was on the internet.
¯\_(ツ)_/¯Hey! Haha! Yes, I know apps don’t have one or the other :laughing: - I was just saying that this would have been an architectural and prioritization decision at some point, and I for one am glad they prioritised personal keys. I work with so many APIs where I need to build a whole app just to send a single request. It’s time-consuming as a developer, requires far more thought, and has little benefit unless actually building a purpose-built app.
(I was agreeing with you, and yet I was still corrected) - For a moment I forgot I was on the internet.
¯\_(ツ)_/¯@andywingrave haha sorry, I thought I came off in favor of one over the other. I was saying we could have both. For most scenarios the api key per user with rate limits per base is perfect. And I agree it simplifies things quite a bit for developers and consumers for a majority of use cases.
I was just trying to build a companion application for airtable users and in that less common scenario I am a little limited. But maybe Airtable doesn’t want that who knows :slightly_smiling_face:
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.