Donation Style Games | How to retrieve a user’s items for multiplayer donation
The issue with current mainstream methods
https://inventory.roproxy.com/v2/users/{userId}/inventory/{AssetId}?limit=100
AssetId
Name
Price
Creator (gives owner)
- https://inventory.roproxy.com/v2/users/{userId}/inventory?assetTypes={AssetName}&limit=100&sortOrder=Asc
AssetId
Name
Price
Creator
Because neither of the current popular solutions return the price nor the creator, donation games may utilize extremely inefficient methods. For instance a common use is:
- Retrieve the initial items via either of the top 2 calls
- Use
:GetProductInfo on the every item in the user’s entire inventory to get its creator + price.
This is bad because there are many user’s who own significant assets. Like if you did this process on the Roblox account it would need to do :GetProductInfo for thousands of items. And it doesn’t batch them based on ownership nor does it even tell you who the creator is, so if you need to filter out items created by them (for games like pls donate) you have to do 2 requests for every item in their entire inventory!
→ Current Best 
Server-Side Solution
Recently, @Ransomwavee was able to find a single request that is the elite tier of requests.
https://inventory.roproxy.com/v2/users/%d/inventory/{username-here}?limit=30
It seems to return all their avatar items (NOT gamepasses) that are only owned by the player AND retrieves their robux.
I have recently implemented this in the following:
module.getInventoryItems = function(username)
local allItems = {}
local cursor = nil
-- local baseUrlToGetCreator = ("https://inventory.roproxy.com/v2/users/%d/inventory/%s?limit=100")
-- :format(plrId, assetTypeId) -- Takes ID not String name
local baseUrlToGetPrice = ("https://catalog.roproxy.com/v1/search/items/details?Limit=30&CreatorName=%s")
:format(username) -- Takes String name not Id
while true do
-- append cursor if paginating
local url = baseUrlToGetPrice
if cursor then
url = url .. "&cursor=" .. HttpService:UrlEncode(cursor)
end
local success, response = pcall(function()
return HttpService:GetAsync(url, true)
end)
if not success then
warn("Failed to fetch items for userId", username, "assetType", response)
break
end
local data = HttpService:JSONDecode(response)
if data and data.data then
for _, item in ipairs(data.data) do
table.insert(allItems, item)
end
else
warn("Inventory v2 response missing .data for", username)
break
end
if not data.nextPageCursor or data.nextPageCursor == "" then
break
end
cursor = data.nextPageCursor
end
-- filter to items created by the user and listed for sale
return allItems
end
so that when i call a user like Roblox with
local allItems = module.getInventoryItems("Roblox")
it gives:
Which as you can see from the image up to 999 items they’re selling that
Include price
Are being sold by the selected player
A lot of other info too like UnitsAvailable (for limiteds) and favorites
Limited to only 30 items per batch
Max 999 items per user
Does not show group assets or off-sale
So its able to give a lot of information, but the main limitation is that it really only works if ur doing something like a donation game where u only want to see their items currently being sold and you don’t need hyper precision. This is still much more superior than every other solution because:
- Other solutions require you specifying AssetId. This is less efficient because you need to do requests for each one, meaning wasted requests on empty areas.
- They do not provide the full picture, like only giving assetId and not creator, meaning you need to manually check if each one is owned by the player
→ Less Secure but Viable Way 
Client Side
If its crutial for you to have a precise number of assets without capping it, I also recommend another approach:
However, I’m not entirely educated on this system, you can see @DrKittyWaffles contributions. I believe the main thing here is that:
Includes price + creatpr
Gives both their owned items and for-sale items
Likely gives additional information
Better control (you specify specific assets to retrieve)
Requires 2 seperate calls (Get Inventory then get data)
Runs on the client only (less secure)
A lot more requests (for every new player you need to request all the other player’s data again)
The main concern with this method is security: If it can only run on the client, its prone to user’s tampering with data. This is fine if its for insecure uses (like trying on avatar item previews), but for donation games this option is not viable. The only other secure way would be to have each player request the items of every other players (as this would mimic the server architect). But that’s incredibly inefficient and quickly balloons as each new player is exponential.
