OpenCloud shouldn't need "advanced" permissions to read Premium status of a user

As a Roblox developer, it is currently too hard to read the premium status of a user not currently present in my experience. OpenCloud currently permits us to check the premium status of a player but only if the user has granted us “advanced” permissions; otherwise the field will always return “false”.

This makes no sense. A player’s premium status isn’t private by any means and can be viewed on their Roblox profile:
image


As a side-note, it could also be argued that a user’s ID verification status also isn’t private as the talent hub allows you to check a user’s verification status (which is currently nearly always identical to the user’s ID verification status) but this only works for users which are currently registered on the talent hub so this is much less of a plausible check outside of solely talent hub related cases.


If Roblox is able to address this issue, it would improve my development experience because developers wouldn’t need to resort to web-scraping to retrieve this information which is already public to users.

3 Likes

Why must you read players’ membership status if they’re not in your game?

I have a leaderboard, in which we would also like to show the premium status of each player.

On top of this, the current behaviour of treating premium as private-info just doesn’t make any sense at all since anyone could web-scrape that information anyway. This makes many niche use cases into a web-scraping nightmare, something that shouldn’t be an issue at all.

7 Likes

I would also like this feature added.

As a temporary workaround, you can send a GET request to this API which returns a bool of Premium status:

https://premiumfeatures.roblox.com/v1/users/USER_ID/validate-membership

Although, I do fully agree with your concerns; Open Cloud being made more restrictive than previous APIs has been a major pain point in my dev workflow that I’ve addressed multiple times with engineers to no avail or solution. Open Cloud.

1 Like

Thanks for the feedback - we’re going to investigate if we can make this change, and will follow up either way.

FWIW, with Open Cloud we want to do a few things, including:

  1. Provide stable, trustworthy, coherently designed APIs.
  2. Get as much API surface out as we can (I know it may not always look like this from the outside, but there are lots of competing priorities internally)
  3. Keep everything secure / avoid introducing any new security or privacy issues

In general (and not necessarily about this specific case; still investigating why we have this discrepancy): if we make mistakes, e.g. in service of the second of those three goals, we’d prefer to err on the side of being more conservative/restrictive (easy to fix) than potentially introducing security/privacy issues (more damaging).

So if Open Cloud seems restrictive in general, that might be why.

But like I said, in this case it does seem like we’re potentially overdoing it, and if we can confirm that there isn’t some non-obvious reason to keep this restriction, we’ll look into whether we can change it.

5 Likes

Just following up on this - we got internal approval to make this change, and now it’s just a prioritization question. Can’t make any promises on that front, but I’ll bring it up again this week.

5 Likes

Hey folks, this change has been actioned and you can now get the actual value of the premium without having the advanced scope, as well as for other users than the one who authorized the API key / app.

Thanks for your patience!

(cc @Rolimon)

5 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.