Updated to recommend using PlayerOwnsAssetAsync specifically, thanks for the feedback.
Emphasize to call PlayerOwnsAssetAsync on the server rather than the client.
Good morning creators
We are making a change so that the Roblox game client enforces users inventory privacy settings going forward. This involves a change in behavior of PlayerOwnsAsset/PlayerOwnsAssetAsync, starting January 27th, 2026.
Today, this method can be used on the client side (via LocalScript) to check if another player owns an asset. For now, no changes will be made for calls originating on the server. But for calls being made from a LocalScript, if the call is made for one player checking another playerâs inventory, the inventory privacy setting will take effect next month, and the method will throw an error.
If this is important to your experience, please make sure your experience is calling PlayerOwnsAssetAsyncon the server (not the client) by January 27th, 2026.
For now, this change only applies to assets, but we may explore and announce similar changes for other inventory item types in the future in order to enhance privacy on Roblox.
This change also applies to all web endpoints exposed via inventory.roblox.com (v1, and v2). If you are consuming the web APIs directly, please use our Open Cloud Inventory endpoints which support API keys and OAuth.
Iâm not entirely sure what the use cases on the client are (avatar editor games?)⌠but less than 3 weeks is pretty short notice for this change. Shouldnât it be a few months, and also mention that PlayerOwnsAssetAsync should be used instead?
Thanks for pointing this out, yes we strongly recommend everyone to put the feedback in the right announcement so the right Roblox teams see your feedback â we are the teams working on Open Cloud and player inventories.
And there it is. This patches the method which has been used for a long time now to get a complete list of Roblox limiteds that any user with a private inventory owns, as well as each UAID.
This is the nail in the coffin for any community project like this (including my 170+ owner lists created for these items, to assess how many copies exist for each of them), but itâs completely understandable and Iâm surprised this didnât happen sooner because it has been abused to hell and back. Iâve encountered several developers that own these limiteds and dislike having a target on their back for this information being publicly accessible through these APIs.
It says âfor nowâ when talking about changes to the server. If we do see changes there, can we get an improved way of detecting successful bulk purchases that are exploiter proof? Currently, the only way to do it is to check item ownership on the server before prompting the bulk purchase, and then checking again after the client sends a success state.
Firstly, PlayerOwnsAsset is deprecated and you should use PlayerOwnsAssetAsync instead, but also kinda a useless update.
The reason why this is a useless change is because I donât believe this would be abused or be efficient if abused. Itâs not like the function is grabbing everything the player has, it only checks one thing at a time, there are many MANY assets on Roblox so it would take forever to check every asset id, therefore this wouldnât be abused all much.
unfortunately, youâre right. I run a Discord bot called RoUtility, widely known for having a command called /rap using these exact APIs to fetch usersâ limiteds while they have their inventory set to private, so this was practically inevitable. I donât think anyone can seriously argue that those endpoints werenât abused (especially since you have to make 2,560 requests to the API for every item). Having full ownership visibility for users with private inventories was always going to end this way, and I get why people (especially devs with expensive limiteds) didnât like having a spotlight on them
aside from all the abuse - there has also been legitimate use with these capabilities, one of the reasons high value collectible account compromises are often detected quickly is because sudden inventory changes become visible and traceable through these APIs. when ownership tracing methods disappear entirely, it becomes easier for stolen items to move in silence
and also while weâre on the topic of privacy, this friends search endpoint:
appears to leak partial friend data for UK users due to OSA-related restrictions (as discussed in the post here). If inventory privacy is being tightened, it would be good to also review this endpoint and fix it up.
The âfor nowâ in this statement is a problem. We use server checks to make sure a player owns certain items before granting them rewards in game. We canât check this on the client because then the server doesnât have control over the value (players with exploits could grant themselves rewards by sending that call back as true). âFor nowâ isnât good enough, we need this functionality permanently.
i really never seen the big deal about letting other people see your limiteds, what difference does it make? i mean i have a few limiteds for years and never so much had anyone ask to buy them since trading was removed.
I owned Blue Clockwork Headphones and as soon as they went limited I received multiple messages on Discord trying to steal them from me by asking me to verify their legitimacy (using the accept trade api).
Iâve also heard stories of people receiving phone calls asking for their limited items. Having them visible to the public can result in many problems.
I use this to check if the user owns an avatar item before allowing them to purchase it, and the item typically isnât created by me. Any avatar customization/shopping experience would do this.
I have also seen some games use this to grant rewards associated with stuff like toy code items, and those items are typically published onto the âRobloxâ account.
I assume this is also going to apply to PlayerOwnsBundleAsync too? The original announcement doesnât mention this.
Iâve never seen PlayerOwnsAssetAsync as a big concern because, unlike AvatarEditorService:GetInventoryAsync() (which is already locked behind an inventory access prompt), you can only check one item at a time, so scanning large amounts of items wouldnât really be feasible.
