The Shiny usage information endpoint in the RStudio Connect API has the following (documented) restriction:
If the user calling the endpoint is a publisher, the data returned will be limited to those applications owned by the user.
This means that by default a user won't get any data back for apps in which she is collaborator (but does not own), which is extremely annoying for collaboration projects.
Is there a way to enable collaborators to get this data? If not, how do you suggest to proceed if someone would like to set up a small application gathering usage data across multiple apps in an enterprise level?
Hi @joseluizferreira - Thanks for your post! This is a really interesting use case. As you point out, the instrumentation data API doesn't currently support collaborator access, only content ownership.
Are the applications you're looking to gather data on all owned by the same publisher account, or multiple accounts?
If they're all owned by the same publisher, it could be fairly simple for that app owner to set up a scheduled R Markdown ETL process that gathers their own instrumentation data, filters it down to the applications their interested in sharing with this collaborator, and pushing that filtered data out as a published Pin or R Markdown output data file which can then be directly access restricted to the collaborator like any other piece of content on Connect.
If the apps are owned across several publisher accounts, you could potentially follow a similar R Markdown ETL pattern as described above, but with an Administrator API key - being extra careful to filter down for only the application GUIDs that the collaborator should have access to. The use of an Administrator API key would probably take some negotiating, of course, and might be a non-starter entirely depending on what your internal policies are.
I'm happy to write this up in more specific detail if you'd like. I'll also raise this case as a feature request to our product teams as we examine the future of the Connect API work. Thanks so much for sharing. Please let me know if this was useful at all.
Thanks for the detailed reply. I talked with one of the admins after posting this and we figured out a safe setup using an admin API key. It worked perfectly!
Since you've said you could ask for a feature request regarding this issue, I'd be very interested in suggesting an associated thing.
It would be very helpful if the content information endpoint /v1/experimental/content/{guid} could return a list with all the contents if guid is not provided (i.e. in the endpoint /v1/experimental/content). In the app that I mentioned above, I have currently to make one request per GUID just to be able to get minimal information, such as content title.
Secondly, we are also experimenting tag schemes and unfortunately the content endpoint does not return this information at the moment. This is again a functionality we'd like to see in the future.
Are those requests something you can raise with the team? Please reach out to me if you need extra information or if I need to do something, I'd be very interested in helping with that.