Is it possible to access private pluginData through the REST api?

According to the client library documentation, if I store data using for example t.set('card', 'private', ...), that data should be private to the local user (not the powerup but the user the way I understand it).

If that is the case, shouldn’t it be possible to access private data through the REST api, as long as you are doing so with the credentials of the user who stored said data? I already tried, and it doesn’t seem to be the case. In fact it doesn’t seem to be accessible at all. For example if I try to access private data of the current user using /1/members/me/pluginData?key=<key>&token=<token>&access=private, with the credentials of the user and the powerup that created the data through the client library, I get a 401 reply, suggesting accessing private data through the api is not allowed at all.

Unfortunately I was not able to find anything about how this works in the documentation. Can anybody clarify how private data is actually supposed to work and if it can be accessed outside of the client library at all?

You’re correct that when a Power-Up stores plugin data via t.set with a private scope that it is available only to the user who is actively using the Power-Up. Where you can access the data via the REST API depends on which Trello object is used when calling t.set: card, board, or member.

If the data is stored on a member (t.set('member', 'private', ...) then, as you mentioned, the data is available via /1/members/{memberId}/pluginData so long as that member’s key and token are used. If the data is stored on a member in the shared scope, then anyone that has read access to that member can also read that data. For instance, because I’m a public Trello member, anyone can see the shared pluginData on my member: https://trello.com/1/members/bentleycook/plugindata

Similarly, the same pattern goes for data stored against a card or board scope. If it is stored as shared, anyone that has read access to the card or board can see the data via the /1/boards/{boardId}/pluginData or 1/cards/{cardId}/pluginData routes. For instance, anyone can see the shared pluginData on a public board: https://trello.com/1/boards/LmBFwbBK/pluginData.

Data stored in the private scope against those objects is accessible at the same routes but requires the key and token of the user who was active when the data was stored.

The 401 you were seeing is unexpected. Does the following work request work: GET /1/members/me/?key=<key>&token=<token>? I have a sneaking suspicion that you might be using a bad key/token combo because even if there is no data, you should still get a 200 response.

Edit: I was wrong about the private scope on a member. That data is never accessible via the API, regardless of whether you have a valid key/token. Privately scoped pluginData can often contain secrets, and is therefore deemed too sensitive to allow consent tokens to access.

Thank you for the clarification Bentley. Just to complete my (and others) understanding of this: Will data stored in the private scope be subject to the same storage limits as data in the shared scope like the documentation implies or has every powerup it’s own private scope and data limits? And if the private scope is shared by all powerups: is it possible at all to know if there is still room to store something?

Going to split this up into two questions to try to reduce confusion.

Has every Power-Up it’s own private scope and data limits?

Yes, each Power-Up is given its own storage limit per a scope/visibility pair.

Will data stored in the private scope be subject to the same storage limits as data in the shared scope?

Yes, your Power-Up will be able to store up to 4096 characters in each scope/visibility pair. That means you can put up to 4096 characters in each of private-member, private-board, private-card, private-organization, shared-member, shared-board, shared-card, and shared-organization. In total, you have 32,768 characters of space across all of the pairs.

Awesome! Thank you very much for the clarification.

Maybe it would be nice for somebody to take a look at the relevant pieces of developer documentation. Most of what you just clarified is only covered in somewhat ambivalent terms spread over multiple locations…