Updates To MarketplaceService GetProductInfo Return Values

Updates Announcements
,
1

Hi Creators,

To support platform health and legacy structures, on July 6, we’re changing the behavior of the ID field returned within the creator information from MarketplaceService:GetProductInfo and MarketplaceService:GetProductInfoAsync.

Currently, these MarketplaceService calls return creator information as part of the response. This update alters what the ID field returns depending on the creator type to clean up our data features.

When this change goes live, the ID field will return specific values based on the account type:

  • ID = userId if the creator is a User
  • ID = 0 if the creator is a Group

How To Update Your Game Scripts

To ensure your scripts handle this update correctly, we recommend adjusting how you check creator data. In general, we still recommend using the combination of CreatorType and CreatorTargetID rather than the standalone ID field.

  1. Review any scripts in your games that call MarketplaceService:GetProductInfo or MarketplaceService:GetProductInfoAsync.
  2. Check if your code relies on the ID field for groups.
  3. Review your scripts, check your logic, and update your code to use the recommended fields.
  4. Link to documentation: GetProductInfo
-- Recommended way to read creator info
local MarketplaceService = game:GetService("MarketplaceService")
local success, info = pcall(function()
    return MarketplaceService:GetProductInfo(assetId)
end)

if success and info then
    local creatorType = info.Creator.CreatorType
    local creatorTargetId = info.Creator.CreatorTargetID
    -- Use these fields instead of info.Creator.Id
end

Please let us know if you have any questions.
Thank you.

FAQs

Should I Stop Using The ID Field Entirely?

  • Yes, we recommend using the combination of CreatorType and CreatorTargetID instead of the ID field to ensure your game scripts remain stable.

Will This Change Break My Existing Live Games?

  • If your scripts explicitly depend on the ID field returning a non-zero value for group-owned assets, you must update them to avoid failures.
33 Likes
2

This topic was automatically opened after 11 minutes.

3

Could we get more detail on how this supports anything better? As far as I can tell, this changes existing behaviour without making anything new possible.

36 Likes
4

Is this really worth breaking backwards compatibility for? Can’t we keep the existing behaviour with recommendations to use the new method?

19 Likes
5

I’m assuming Creator.ID can be the ID of whoever last updated the product in the web API? So that’s why this change is being made?
But otherwise this doesn’t make any sense just based on this announcement.

1 Like
6

The Id in the creator field represents the Agent ID, with users it is known as the User ID. Groups’ agent ID can not be used anywhere except legacy purchase web endpoints.

6 Likes
8

Does this mean that the return value will finally be typed instead of any

2 Likes
9

I would not recommend doing this. Any existing code using only Id and CreatorType is already broken for groups because Id is the Agent ID, not the group ID/creator target ID. This will also break code that utilizes the fact that each group and user have a unique agent ID. Please see this group-owned asset for reference: https://economy.roblox.com/v2/assets/1441335069/details.

8 Likes
10

-- holy claude. please do not just shove out AI-generated code here, you’re just going to end up confusing people especially when the code itself is just, not valid

2 Likes
11

This update seems to create more inconsistencies than it solves. Instead of making the API cleaner, it forces us to rewrite perfectly functional legacy code just to handle a 0 value. If CreatorTargetId already correctly identifies the group or user, Creator.Id should either do the same or be deprecated gracefully, rather than returning misleading data.

1 Like
12

What “legacy code” actually even uses this that is in use in any games that would be meaningfully impacted?

4 Likes