Coda very much needs a way to create API keys per document - and preferably also read-only API keys per document.
I am using coda to create a website, which means that I need to pull data from a coda document when the site is being built. This means I need to store the API key at my build host - encrypted of course, but still accessible by anyone who has access to that repo. Now, this API key has full access to all my documents, so anybody with access can pull all my private data as well! Not only that, but somehow Coda seems to have linked my two google accounts (work and private) together, and I am seeing documents from two different google accounts when listing all documents - which means that some of my private projects can see all my work data and vice versa.
This is an impossible situation. What a build host, or any sort of automated API integration, usually needs is just access to a single document - and single document API keys would solve that need perfectly. Even more perfect would if there could be separate read-only API keys, as often the integrations just read data.
Hey @Nuutti_Kotivuori1 - we hear you, great suggestion! For our beta API we went with a single API key for simplicity, but longer term we’re looking into supporting various scopes, i.e., access to specific docs.
One thing I can recommend for now as a workaround is to share your Coda doc in read-only mode with a separate Coda account (you’ll need another Google account for now) and then use that account’s API key. That way that key would only have access to docs designated to that build account. I know this isn’t that great or scalable of an option, but hopefully it can unblock you on your project.
Thank you for the swift answer. I think I will go with the workaround for now.
For future, I’d like to mention that you might consider if all keys actually belong to users. For a corporate scenario, and integration, it would make sense that access keys would belong to certain documents - and that everybody with access to the document could see and manipulate the keys. That way, for example if a person leaves an organization, or a document, any automation that uses the document will not break.