Requesting an adjustment for my experience's AvatarEditorService throttling

As noted on the AvatarEditorService documentation, my experience requires an adjustment of its’ experience-wide throttling.

Recently my experience (Lucky Avatars! [Outfits Catalog] - Roblox) has been spiking in popularity (averaging 500 active players), and I foresee future growth that will result in requests exceeding the current rate limit.

To continue smooth operations and functionality in-experience, I’m requesting the throttling rate limits are increased in my experience to allow further requests on the following endpoints:

1. AvatarEditorService:GetRecommendedAssets() and AvatarEditorService:GetRecommendedBundles()

In my experience, when a user selects an item on their avatar, customize options are populated leveraging AES:GetRecommendedAssets() and AES:GetRecommendedBundles(), respectively. These calls are only made upon opening the inspect menu (which by default is closed), to limit requests sent to AES. Because these results are personalized to the player and localized to each player’s language, they cannot be cached and shared amongst other players in the server, hence requiring 1 request for each asset/bundle inspected.

At current rate limits, 6,000 requests are allowed per minute. So, if there were a few thousand players online (getting close already, and game has only been out for a week), you can see that this would quickly hit throttling limits. On average, players seem to inspect about ~5-10 items per minute.

2. AvatarEditorService:GetItemDetails() and AvatarEditorService:GetBatchItemDetails()

Primarily, I use these endpoints to gather pricing information. Where most of the calls are to capture pricing data on bundles (as this information can only be fetched via these endpoints, as MarketPlaceService does not return pricing data for bundles).

For the most part, I leverage existing incoming information to cache pricing data (like storing the data that is passed alongside calls to GetRecommendedAssets() and GetRecommendedBundles() and/ or using MarketPlaceService:GetProductInfo() to get pricing data for non-bundle items, assets.

However, upon loading bundle information (where price needs to be shown to the player, as to allow them to click a button to purchase), I must use AES:GetItemDetails() or AES:GetBatchItemDetails(). These requests are only made when a buy button must be populated on the screen. No wasted requests are sent unless the information must be displayed, as to lower my request impact on AES. Despite this, I am still running into issues with the throttling limit. Whenever I user inspects an item / loads the purchase / save screen, pricing data must be populated, where on average, as noted above, ~5-10 items are inspected on average per minute per player (and can be more, if a user aims to purchase/customize all items on their avatar).

As outlined above, I am requesting an increase in allowed requests to avoid hitting throttling limits for:

  • AvatarEditorService:GetRecommendedAssets()
  • AvatarEditorService:GetRecommendedBundles()
  • AvatarEditorService:GetItemDetails()
  • AvatarEditorService:GetBatchItemDetails()

If any further questions or clarifications are needed on how, where, or why I am making these requests, please let me know. My aim is to limit my AES usage so as not to create unnecessary demand, but ultimately, my experience does require rate limit increases to scale with its’ player usage growth.

Thank you for the help,
Sam

4 Likes

This whole adjustment and rate-limiting process seems really clunky, for what it’s worth. Why is there a hard cap of 6,000 requests per minute, regardless of game size? Requesting a “rate limit increase” as a feature request, especially on a public forum, doesn’t make sense either. Why isn’t this in the Developer Hub, under some Rate Limits tab, where you can request this? Also, could this not be something that is, more automated as well?

I was even more baffled when they announced the (to fairly quickly reverted) marketplace policy update, which made you use these APIs that use this exact rate limit. How could you even feasibly use that for most popular games, without an increase?

4 Likes

It would be nice if they could make some sort of API feature to load a cached version of the information if it is being throttled instead of waiting for the updated. However, limits like these are quite unreasonable.

2 Likes