The next generation of the Quickbase API
The next generation of the Quickbase API When we first released our library of Quickbase APIs, it was a historic moment. We were far in front of the rest of the market in making it easy for people...
Forum Discussion
@Harrison Hersch this would be for an EOTI permissioned app. What I am trying to accomplish is category #2 above. Not cross-domain communication within QuickBase.
That's what prompted my question in the first place because in my experience I would expect an API to be "open" (not restricted by CORS) but require token based authentication for private resources.
If a QuickBase app has an EOTI user with permission to access a table, then that table isn't considered a "private resource" and the user token is not required.
It is up to the dev to permission the EOTI user with the appropriate access. The source of the request (client-side or server side) shouldn't matter.
If a web app is hosted, for example, on AWS S3 should this theoretically work with the new API? But not currently with the existing API?
That's what prompted my question in the first place because in my experience I would expect an API to be "open" (not restricted by CORS) but require token based authentication for private resources.
If a QuickBase app has an EOTI user with permission to access a table, then that table isn't considered a "private resource" and the user token is not required.
It is up to the dev to permission the EOTI user with the appropriate access. The source of the request (client-side or server side) shouldn't matter.
If a web app is hosted, for example, on AWS S3 should this theoretically work with the new API? But not currently with the existing API?