I’m happy to add in a function to return only keys to the storage API - though I can’t promise I can add it quickly. In the interim, I’d suggest maintaining a list of keys in a known item. That should get you the same functionality you want at only a slight inconvenience. If you are planning to store a massive amount of data using our storage API, please let us know. It’s generally meant for small items like config settings and the like.
I might look into restricting the fields returned by calls under the /v1/app hierarchy, but given that this isn’t actually meant for anyone to use beyond the dashboard, it would be low priority. In the case of applications, a lot of extra data is returned - that’s for certain. However, this only becomes an issue for a user that has hundreds of apps. If you are planning on managing that many apps, then we definitely need to talk further.
Looking at the user data - we tried to compromise on what would be immediately useful for the dashboard vs. bandwidth. If we just returned a list of user IDs, we could save 70 bytes per user, but then how would you identify which users you wished to retrieve? At a bare minimum I think ID and email are required. At that point we’re really just talking about saving maybe 35 bytes per user record - which means that if you have 1000 users, you’ve transmitted an extra 35KB, which seems like a small savings for added API complexity.
Let me know if there’s a use case I’m not thinking of here.