MarketplaceService:GetProductInfo() should return more consistent results for bundles

Feature Requests Engine Features
#1

As a Roblox developer, it is currently too confusing using MarketplaceService:GetProductInfo() for bundles because the results are inconsistent with the other info type inputs. Let me explain what that means better. All the other InfoTypes (excluding subscriptions and bundles) will return the following: Creator, Created, PriceInRobux, IsForSale, IsNew, MinimumMembershipLevel, ect.

However, this is not the case for bundles. When getting information on a bundle, :GetProductInfo() will only return the following:

{
  ["BundleType"] = "AvatarAnimations",
  ["Description"] = "Party like its 2006. Relive the glorious old days with this retro style animation pack.",
  ["Id"] = 667,
  ["Items"] =  â–¶ {...},
  ["Name"] = "Oldschool Animation Pack"
}

Since this is inconsistent with the other info types, it is confusing why it doesn’t return some of the basic information (price, creator, ect.) like the other types. In fact, there’s been a least two occasions where people have noticed this:

As you can see, the issue with :GetProductInfo() is that it doesn’t provide information that developers have expected it to provide for bundles.

Yes, developers will be able to use AvatarEditorService:GetItemDetails() instead of MarketplaceService:GetProductInfo() for information on bundles in the future. However, leaving MarketplaceService:GetProductInfo() without some of the basic information for bundles will confuse many developers. I say this because it confused me yesterday and it took a bit of searching than normal to find AvatarEditorService:GetItemDetails().

This feature request is not asking for GetProductInfo to return what GetItemDetails returns for bundles, but rather just a little bit information about bundles (at the very least Creator, PriceInRobux, and IsForSale). Providing this bit of information so that GetProductInfo for bundles is more consistent with the other types would be a nice small change.

If Roblox is able to address this issue, it would improve my development experience because I would be able to use MarketplaceService:GetProductInfo() for all types of assets instead of having to use AvatarEditorService:GetItemDetails() for some basic information on bundles.

11 Likes
The price of a bundle should be included with AssetService:GetBundleDetailsAsync()
#2

As you outlined above, this feature already exists and is in beta. AvatarEditorService has only partially released to the public. The catalog methods will release later this year as stated in the original announcement.

#3

This feature actually doesn’t exist. This feature request is about Marketplace:GetProductInfo() and it not returning enough information. The feature request is also partially about consistency between results returned by the method.

Like mentioned in the feature request, AvatarEditorService is only useable on the client. So even when AvatarEditorService:GetItemDetails() is available, this problem will still not be solved. This is because the server still won’t have access to the other information about bundles. There are legitimate use cases for having such in info on server:

The example above is actually possible for other marketplace assets through the usage of :GetProductInfo(), but not bundles since the method doesn’t provide a price.

#4

GetProductInfo isn’t going to be updated because it’s being superseded by GetItemDetails as previously stated by engineers.

It would be better to request usability of this new function on the server once it releases if that is still the case by then. Although from what I can tell in the documentation, this doesn’t seem to be the case nor would it make sense for engineers to have made it available only on the client. I don’t quite understand the point of this feature request if a better alternative that returns more info is already available in a closed beta.

#5

I’d like to see proof of this.

You’re under the assumption that GetProductInfo will be depreciated. That wouldn’t make any sense because that would mean you would have to use AvatarEditorService:GetItemDetails() to get the information for something like a plugin, gamepass, or even a developer product. It only takes in AvatarItemType for the itemType parameter. MarketplaceService:GetProductInfo()'s infoType parameter uses InfoType, which covers all bases. Why would such a method be underneath AvatarEditorService instead of MarketplaceService?

#6

The previous featured request you originally linked, was denied by an engineer because the new AvatarEditor:GetItemDetails will return all available bundle data. This feature request is exactly the same as that one except for GetProductInfo instead of GetBundleDetailsAsync. You both are requesting more bundle info details which will be resolved by the new GetItemDetails as stated by @TheGamer101.

#7

I asked for proof that “GetProductInfo isn’t going to be updated … as previously stated by engineers”, and the proof you’ve provided isn’t sufficient to come to that conclusion. Nowhere in that reply is there mention of GetProductInfo not being updated anymore due to GetItemDetails:

If anything, that reply is implying that GetBundleDetailsAsync is being depreciated, which is not GetProductInfo. You’re implying GetBundlesDetailsAsync is the same as GetProductInfo, but that is not the case.

#8

I believe you’re misunderstanding. GetItemDetails exists to provide all available data to developers for assets and bundles. They’re not going to update GetProductInfo to do what GetItemDetails already will do when released to the public.

The problem you outlined in the original request is already going to be resolved by the new GetItemDetails. Although I understand you want GetProductInfo to return the same data as GetItemDetails, it simply does not make sense for engineers to go back and implement a solution to an already solved problem. It is quite clear that GetItemDetails will be the preferred way of fetching data about assets and bundles once it fully releases.

Although you have claimed GetItemDetails is available only on the client, I cannot find any official documentation to back this up. Nor would it make sense because GetItemDetails has to make a request to the server to retrieve the data in the first place.

#9

This is my last reply to this chain of posts because this should not be happening in a feature request thread.

Just looked into it and yes, AvatarEditorService:GetItemDetails() can be used on the server. I won’t go into why I thought there was the possibility that only the client could use it since that is irrelevant. I did indeed claim at one point that “AvatarEditorService is only useable on the client” in one of my replies. Not quite sure why I said that because I know that there are other methods from it that can be used on the server already.

Not sure why you’re explaining why it exists since I’m not even debating its existence. All I was pointing out was that your claim about GetProductInfo not being updated anymore unfounded.

That being said, I still believe that this is a valid feature request because having more consistency between the results returned by different info types for GetProductInfo is useful. Now if the engineers decide that this feature is not necessary, then so be it. Neither you or I can decide that. It’ll be some extra work for me and potentially confusing to people in the future when GetItemDetails is available, but it is what it is.

I’ll go ahead and edit the feature request to be more direct and clear.