Is there any way to create a read-only table view that can be accessed anonymously via the API?
I just want to be able to do a simple table lookup/mapping (with a filter formula) with a front-end Javascript call without exposing an API key (or having to host a back-end script on a 3rd-party server).
Alternatively, is it reasonable to create a “collaborator” account with read-only access and expose that account’s API key?
Best answer by kuovonne
Thanks for the explanation of your back end restrictions.
Since you are okay with sharing the entire base, using the api key for a read-only collaborator sounds like it will work. Just make sure that no-one grants that collaborator any additional access. You can give that collaborator an email address with a very clear name that indicates the purpose of the account.
If this answers your question, please mark a post as the solution. Otherwise, could you please give a bit more details?
+29Do you want read-only access to only a single table, or to the entire base?
If you want access to only a single table this is a bad idea because the API key has access to the entire base.
On the other hand, if you are okay with exposing the entire base and and allowing strangers to copy the entire base, this sounds reasonable to me. Just make sure the user has only read-only access to the base and no other base, And make sure that everyone with the power to change that user’s permissions or add that user to another base is properly trained to not do so. And make sure that you trust everyone with that power.
+29Where is this front end code being served from? Are you hosting you front end on a service that doesn’t allow for back end code?
Do you want read-only access to only a single table, or to the entire base?
If you want access to only a single table this is a bad idea because the API key has access to the entire base.
On the other hand, if you are okay with exposing the entire base and and allowing strangers to copy the entire base, this sounds reasonable to me. Just make sure the user has only read-only access to the base and no other base, And make sure that everyone with the power to change that user’s permissions or add that user to another base is properly trained to not do so. And make sure that you trust everyone with that power.
Thank you, kuovonne. The entire base would be one table with two columns of non-sensitive information.
The front-end is a SAAS marketing funnel. It can host data, but it won’t execute server-side code.
+29Thanks for the explanation of your back end restrictions.
Since you are okay with sharing the entire base, using the api key for a read-only collaborator sounds like it will work. Just make sure that no-one grants that collaborator any additional access. You can give that collaborator an email address with a very clear name that indicates the purpose of the account.
If this answers your question, please mark a post as the solution. Otherwise, could you please give a bit more details?
Thanks for the explanation of your back end restrictions.
Since you are okay with sharing the entire base, using the api key for a read-only collaborator sounds like it will work. Just make sure that no-one grants that collaborator any additional access. You can give that collaborator an email address with a very clear name that indicates the purpose of the account.
If this answers your question, please mark a post as the solution. Otherwise, could you please give a bit more details?
The very few security cells in my body make me want to ask -
How is openly sharing an API key something anyone should be OK with?
When shared like this, any exposure of another base ID in that user’s account would allow someone full access to other data, wouldn’t it?
Wouldn’t the better approach be to create a proxy service that abstracts access to the data without exposing the API key while allowing read-only views be far safer?
+29The very few security cells in my body make me want to ask -
How is openly sharing an API key something anyone should be OK with?
When shared like this, any exposure of another base ID in that user’s account would allow someone full access to other data, wouldn’t it?
Wouldn’t the better approach be to create a proxy service that abstracts access to the data without exposing the API key while allowing read-only views be far safer?
Well, I don’t really like sharing API keys. In my original post, I also made it very clear that the read-only user should have access only to that base and to make sure that you trust that no-one will ever give that user access to any other bases or additional permissions. I don’t know if I’d ever to do this, but I haven’t been in a situation where I can’t run server-side code or use a 3rd party service.
@Brian_Katzung can’t run server-side code, and doesn’t want to use a 3rd party service.
This post from Airtable’s engineer of the API key suggests that this situation is okay.
Well, I don’t really like sharing API keys. In my original post, I also made it very clear that the read-only user should have access only to that base and to make sure that you trust that no-one will ever give that user access to any other bases or additional permissions. I don’t know if I’d ever to do this, but I haven’t been in a situation where I can’t run server-side code or use a 3rd party service.
@Brian_Katzung can’t run server-side code, and doesn’t want to use a 3rd party service.
This post from Airtable’s engineer of the API key suggests that this situation is okay.
Oh, yeah - requirements constraints make us comfortable with nutty ideas sometimes. This is also why I have like 9 security cells in my vastly fat body. :winking_face:
For now, you can create a separate “API user” and share the base with them as read-only. That user’s API key will only have read access to the base.
Um, won’t this cost an additional $24/month?
+29Read-only users are free.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
