Get all owned gamepasses?

Is there a way to get all gamepasses/badges that are owned by a player in a certain game?

Using a bunch of separate requests for each gamepass ID might exhaust the API, and error. Some function like MarketplaceService:GetOwnedBadges(player) that would return a table of all owned gamepass IDs would be cool. Does something like that already exist?

I tried many ways, nothing will do this I know of. You could test for each gamepass at the start then set up a variable so you don’t need to keep checking that. theyhavethisgamepass = true. IDK …

1 Like

This is exactly what Im doing currently.
There is a table that contains all of the owned gamepasses thats replicated to the client.
It checks for all gamepasses at once on startup, and adds to that table when a new gamepass is purchased.

It works, but its probably not ideal, especially with more gamepasses

I just use a script for each pass at the start and they are delayed a bit from each other to not jam up the works.

Good question.

After a quick MarketplaceService - Roblox API Reference scan I didn’t see any bulk request option. Official MarketplaceService | Documentation - Roblox Creator Hub doesn’t say anything about it either. Same with BadgeService.

With a moderate amount of badges and gamepasses a number of requests on player join doesn’t sound like an issue, but I understand that it may eventually raise concern about the limits.

I would probably take a look at how many gamepasses/badges we are talking about. Maybe have a variable storing the number of requests made in a minute and account for it. And like you said, store the new gamepasses. Just in case player rejoins the same server later, you could keep the information about gamepasses and badges for some time before deleting it as well.

Also, it’s worth remembering that players can delete badges and gamepasses from their inventory.

Considering that, one alternative could be storing badges in the data store. If player removes the badge, they probably don’t want it. And then you only have to check for the badges not yet acquired. All this comes with slight risk of course.


I’ll collect some information about the limits. The list is (kind of) still in progress.

Especially the lastest post I’m listing raises some more confusion. If clients can do what the thread describes, we are facing a fairly serious problem that has to be addressed.

Important distinction: HttpService request limit of 500 req/min doesn’t necessary (and most likely doesn’t) match HttpRbxApiService limits.


(May 2022) 100 req/min per server. || MarketplaceService:GetProductInfo() Rate limit

MarketplaceService:GetProductInfo() Rate limit

(Feb 2022) 500 req/min + 100 req/min per player || Rate Limit for MarketplaceService:GetProductInfo()?

Rate Limit for MarketplaceService:GetProductInfo()?

(Jul 2021) :GetProductInfo() capped at 100 req/min. || RequestQueue | Easily handle rate limits using Promises

RequestQueue | Easily handle rate limits using Promises

(Jun 2021) API web calls capped at 600 req/min for server scripts and 300 req/min for local scripts || MarketplaceService:getProductInfo() Roblox API ratelimit

MarketplaceService:getProductInfo() Roblox API ratelimit

(Jun 2020) API web calls capped at 500 req/min for server scripts and 300 req/min for local scripts || Allow unlimited MarketplaceService calls for plugins

Allow unlimited MarketplaceService calls for plugins

(Dec 2018) MarketplaceService limit reached at 100 req/min. || How many GetProductInfo request can I do per minute

How many GetProductInfo request can I do per minute?

EDIT.

Some tests may be flawed, stemming from the possibility that returned information may become cached (perhaps for a short time).

3 Likes

Okay, wow. I did not expect a thorough reply like this. But I guess it does ultimately raise more questions that answers.

Its kinda weird how the limits of these functions are not officially documented.

I was also looking around in the api like inventory and games, but no luck. There was 1 function that seemed interesting, since it requires the user id, asset type and “targetId”, but unfortunately the target id is the id of the actual gamepass, not game. So in the end it just returns the badge info, which is not useful at all.

This was more of a futureproofing question, I actually only have 4 gamepasses right now, so this PROBABLY shouldnt be an issue. I will stick to that method I mentioned earlier for gamepasses, and just check for badges only when needed. (Responsiveness in gamepasses is quite important in this case, checking the ownership every time would not be good for things like a double coin gamepass, since it would create a ~0.5s delay each time you get coins)

1 Like

Yeah lol, looking back I really made an elephant out of a fly. But it’s more about the lack of clear documentation and an interesting idea for a feature proposal.

This was just meant as a collection of some threads/topics I thought were relevant. Maybe I missed something (thought it must have been quite hidden in that case :slight_smile:) or the information and tests in them are flawed or outdated.

In my projects, I don’t check for every gamepass ownership after the initial quiry. So if player makes a gamepass purchase during the gameplay, I’ll know because of MarketplaceService events, and if they purchase gamepasses on the website, they’ll usually have to rejoin, unless the check is performed once the player tries to access some game feature. It’s been like that for a majority of games since I remember.

I ran into something else you may find interesting.

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