Provide items in bundle through AvatarEditorService:GetBatchItemDetails()

As a Roblox developer, there are too many APIs that exist to get item details about a bundle.
The newest API, AvatarEditorService:GetBatchItemDetails() allows to get details for both bundle and asset data types. However, for bundles this does not provide a list of items that are included in the bundle.
If you want to get this information, you must make an additional call to AssetService:GetBundleDetailsAsync()
If Roblox were to address this issue, developers will be able to more easily create avatar marketplaces without the headache of discovering all of these alternative methods.

These two methods also return different BundleTypes. You can see the avatar editor service API provides “Animations” as the bundle type, and the asset service API provides “AvatarAnimations” as the bundle type.


It seems like “Animations” is the accepted/new bundle type.

8 Likes

I don’t think we would want to include all the bundle items in the GetBatchItemDetails, as this would put unnecessary load on the backend in situations where the bundle details are not needed. We see the use case for GetBatchItemDetails as you want to display a grid of items or something like this. In this case you wouldn’t need the additional information provided by AvatarEditorService:GetItemDetails like ownership information or bundle items. Providing less information means we can allow you to request the details of more items without us needing to throttle the requests. If you need to apply the bundle when the user clicks on it, you could use AvatarEditorService:GetItemDetails to get the bundle details.

I agree with not including bundle parts in the get batch API. The reason for including them in batch is there is no other way to get the bundle that an asset is a member of. There is already an Roblox API endpoint to get this, but no Lua alternative:
https://catalog.roblox.com/v1/assets/{assetId}/bundles

A replacement to AssetService:GetBundleDetailsAsync() as a method under AvatarEditorService would make more organizational sense, but if documentation can be updated to help developers locate that API that would be good enough!