Allow unlimited MarketplaceService calls for plugins

I’m currently developing a plugin that can search your whole game and list the asset by assetowner.
This requires me to check every textureid, every meshid, sound etc.

It works perfectly fine if I run it from commandline, but when I try run it using my plugin I get the error:

MarketplaceService:getProductInfo() failed because number of API requests/minute exceeded limit for HTTP API throttle. Please don’t issue more than 500 API requests/minute with server scripts and no more than 300 API requests/minute with local scripts.

My suggestion is that plugins will have unlimited API requests, just like commandline. Atleast for marketplaceservice. I don’t see why it should be capped.


Out of curiosity, are you using any form of cache system for this plugin to reduce API requests?

I can understand a game having a lot of textures, but over 500 different ones to me seems a little far fetched?


Why would it not be capped? Imagine allowing infinite calls at once from a single plugin. You’d take down Roblox.

500 per minute is 8 per second. If this plugin is for some kind of analysis that won’t be run very often then it’s worth waiting the time it takes. Make sure you aren’t resending the same request (e.g. if there are 10 decals with the same ID you should only need to do 1 API call)


Perhaps an alternate (although I still don’t see why it is needed) suggestion is to ask for the cap to be increased, as @BanTech said, infinite calls could easily crash Roblox’s servers.

May I also ask out of curiosity what are the practical outcomes of your plugin?

Keep in mind, even if the Lua API didn’t limit you, the rate limits on the web service itself which protect it from denial of service attacks likely would if you’re making enough requests.


Yea I do, I only check one id once.

My game has 60,000 unique asset ids. It’d take 2 hours if I can only run 500 checks per minute.

Understandable, but I hardly think the limit is justified. Roblox does their own check of assets every time someone loads any given roblox game. That’s gotta be atleast millions of checks per minute.

Roblox does a ton of work to merge said requests into an efficient set of bulk queries. We don’t send a request for each individual asset, if we did it would be a huge strain on the web services.

So maybe my suggestion should rather be to add a function that returns the owners given a list of ids?
That’s so far-fetched it’d never be added :confused:

I’d create a http solution but that is also capped to 500. I guess I’m stuck then.

Having the appropriate bulk query APIs available is a much more fruitful request which you could make. If you’re going to do that, specify what your specific use case is, i.e. what particular data you need and why.

The bulk APIs are actually public already, they’re only available as REST APIs right now though, not ingame Lua APIs.

I would like to add my use case for a bulk query API, not necessarily for use by plugins, but also in-game through Lua APIs.

I have a menu that shows players all of the gears they have discovered, and I allow them to filter by a few different criteria. Two of them involve checking if the player owns the physical Roblox-owned item. I currently run these checks using MarketplaceService:PlayerOwnsAsset(), but I have to throttle them significantly to avoid hitting the ~100-125 requests per minute limit (not sure if this is official, but it’s what I’ve found to be the cutoff). Without throttling them, I am met with something like this:

Internal error while fetching asset type because MarketplaceService:getProductInfo() failed because HTTP 429 (Too many requests)

Since there are over 175 individual items, with more to come in the future, this takes a significant amount of time (currently over two minutes) that hurts UX and could be resolved with a bulk query Lua API like this.

Hopefully this isn’t too niche of a use case, but I see many others like the op’s for example that would benefit from this. Thanks.

I would recommend making a separate feature request thread to migrate the discussion on bulk query APIs to.

1 Like