I’m currently working on a 3rd party API that can load catalog items at request.
Whether you’re using it for your own UGC store that can be automatically updated, or for enhanced avatar creation in your game. There’s lots of uses!
I’ve seen a lot of people who provide catalog interfaces, but none of them give you customization or comfortability, they all force you to use their GUI and plugins with a big fat logo on the players screen.
My goal is to make an API service that will send catalog items in batches of data, at request.
We currently have a large amount of items in our rapidly growing database and the ability to provide all catalog items requested quickly, as long as they exist on the Roblox catalog.
This would be a service, not a product. There would be a monthly subscription, giving clients an active API key in our system. Rates will vary depending on what access level you’re looking for (depending on usage rate).
My questions are: Would you be interested? Is there a market for this? If not, what kinds of features would you like to see in order to pique your interest in this?
What would be your main concern (or a “I hope they do this part right”) about purchasing a subscription?
The current catalog API is not accessible in roblox studio or live servers, and only supports batches of 30 items at a time with some strict rate limits when used in a browser.
In order to use the catalog API in your game, you will have to create a third party. Plus, with a rate limit of 30 items per request, it’s not convenient if even practical at all.
This would be for people who want to introduce the ability for players to scroll through Roblox catalog items conveniently.
I mentioned the Catalog API because it’s applicable in third party applications while the AvatarEditorService is applicable to in-game, of which both have methods to batch request item information.
Once again Catalog API isn’t practical because of the 30 item limit, a database would be required to get results within an acceptable amount of time (even with a high end rotating proxy).
AvatarEditorService is rate limited and is quickly exhausted with even just a medium sized player count.
Is there a source for this? Because the documentation directly contradicts that by stating it has an insanely generous rate limit (100 requests per second.) There’s no realistic scenario where even a “medium sized player count” server should be exceeding that amount of requests.
The rate limit is experience based, not server based. (The source for this is the documentation you most likely read to accumulate this reply Here)
the “insanely generous rate limit” or 100 requests per second becomes remarkably frugal compared to a playercount of >10k players.
I feel like even at an experience level, if you’re somehow exceeding that limit at 10k players then that’s a design issue. It shouldn’t be reasonably possible for that to happen unless you’ve designed your systems in such a way that allows players to abuse it.
At that point, anyone who is actually legitimately exceeding such limits and has that many players is more than likely to be using their own backend that they’d have full control over, it’d probably even be as simple as spinning up their own proxy service which is pretty simple to do.
The methods tested to avoid hitting the 6krqpm would functionally disallow players to make more than 0.6 requests per second or 1 request per >1.5 seconds (a perfectly reasonable thing for players to attempt when they’re searching the catalog for cool items they would like to try on–taking into account that some players will attempt to make 2 searches in under 1s due to misspelling or simply just a change of mind)
This is without taking into account the multiple requests that a server would have to make on startup to get the home pages set up with a list of items that are readily available to the player without making specific searches
As mentioned before, with a rotating proxy that would allow the developers to append a result of more than 30 items per 30 seconds (not the officially posted limit-this is unknown but this is my personally tested limit) would not only end up taking over 5 seconds to return (tested with multiple high end rotating proxy servers such as OxyLabs and ScraperAPI) but these rotating proxy services are known to have a less than par success rate (meaning that your players will often make searches that return no results) and end up costing the developer money at the end of the day.
The conclusion that I- and seemingly many other developers have reached while creating a catalog interface within their game is to create our own database. which ends up costing a very large amount of the profit made at the end of the day.
My goal is to lower the cost to achieve a well responsive catalog UI for their players by creating a database that is versatile and funded by crowd, effectively making the service cost less for everybody using it.
When I mentioned a developer being more likely to use their own backend or proxy, I meant completely self-hosted, and not reliant on a third party to handle some arguably pretty basic and simple things for them (it shouldn’t be too difficult for someone with a basic understanding of python, for example, to make a simple rotating proxy of their own with 2-3 VPS servers, which would be more cost effective depending on the pricing of your service)
Something like this shouldn’t need to be over-complicated with “high-end rotating proxy servers” since you’re likely not operating at a scale that demands high-end, and if you are, you should already be turning enough profit to offset those costs to begin with.
The chances are you’d probably even only need one VPS anyway depending on if the host you are using has some means to let your VPS send requests from any additional IPs you pay for.
1st off- one issue here is that it would require FAR greater than 2-3 different servers making requests when your game is returning 200-300 results (generously) or realistically a lot more per search, per player. (simply changing the IP coming from that server doesn’t work- Roblox is smarter than that…)
2nd- there is much more work involved than “making a simple rotating proxy of their own”
3rd- there’s no overcomplication with using a “high-end rotating proxy service”. Even if the playercount is 1, the one player interacting with your game should experience a fast response. If it takes that 1 player 5 seconds to receive results from a search they made then your playercount promptly returns to 0. the overcomplication would actually come from doing far more work creating your own service, just to have it take the same amount of time.