Catalog API Returning Data for Moderated/Deleted Assets Intermittently

[bvetterdays (roman)]

I recently developed a project that leverages the Roblox catalog API endpoints to monitor the moderation status of assets and automatically notify me of asset removals or appeals. The two affected endpoints are:

• POST https://catalog.roblox.com/v1/catalog/items/details
• GET https://catalog.roblox.com/v1/catalog/items/ASSET_ID/details?itemType=Asset

These APIs occasionally return data for assets that have been moderated or deleted, despite the expectation that deleted items should not be returned. The GET API should return a 400 HTTP status code when querying details for a deleted or moderated asset, and the POST API’s expected to still return a successful status code, but not include the moderated item data in the request.

While the expected behavior works 99% of the time (i.e., the item does not return data in items/details and returns HTTP 400 in items/ASSET_ID/details?itemType=Asset for moderated/deleted items), about 100 items daily out of a list of approximately 1,000 return data incorrectly, even though they are confirmed to be deleted. This issue has been affecting my workflow as I am unable to reliably determine if an asset is deleted, leading to false notifications of reinstated assets that are still deleted.

Steps to Reproduce:

Unfortunately, the issue does not have clear reproduction steps, as the behavior is intermittent. However, here is a general outline of my process:

1. Send a POST request to https://catalog.roblox.com/v1/catalog/items/details with a list of asset IDs to retrieve their details, every minute.
2. Occasionally, the API will return data for assets that have already been moderated or deleted.
3. When querying an asset directly via GET at https://catalog.roblox.com/v1/catalog/items/ASSET_ID/details?itemType=Asset, it should return HTTP 400 for moderated/deleted assets. In some cases, it returns 200 along with asset data for deleted items.

Impact:

• This is severely impacting my workflow as I cannot reliably determine the status of assets.
• It has caused me to implement a workaround where I make an additional GET request to https://thumbnails.roblox.com/v1/assets?assetIds=ASSET_ID&returnPolicy=PlaceHolder&size=700x700&format=Png&isCircular=false to check if data.state == "Completed". This API returns the status of the thumbnail, which shows as “Blocked” if the asset is moderated or unavailable. While this confirms whether an asset is truly available or moderated, this extra step consumes unnecessary resources and is unreliable.

Safety Concern:

This issue poses a safety concern because, in the case of assets with inappropriate names or descriptions that have been moderated, the incorrect return of asset data could expose users to rule-breaking content. If the asset has been deleted due to such a violation, it should not return any data.

I will provide affected asset IDs and timestamps when the issue next occurs as a reply to this report.

Expected Behavior

• POST https://catalog.roblox.com/v1/catalog/items/details: Data for deleted assets should be excluded from the data table this API returns.
• GET https://catalog.roblox.com/v1/catalog/items/ASSET_ID/details?itemType=Asset: Moderated/deleted assets should return an HTTP 400 status code and no data.

[bvetterdays (roman)]

This issue just happened again now. As you can see below it returns the data of an asset that is clearly deleted. The asset ID is 113758682408493 and the request was made today at 02:00:45 AM EST.

The API should not return data for deleted items. The API used here is the ‘GET’ one linked in the original report.

[thirdtakeonit]

Thanks for the report! We’ll follow up when we have an update for you.

[BrightYellowElephant]

Thank you for the feedback. We have identified the root cause of this issue and applied a fix. As a side effect of the fix, you may start seeing more 500s in your response so please make sure your application is able to handle that gracefully. However, I would like to point out that catalog-api is not built for fetching moderation status as a use case. If you are monitoring your own creations, the creator dashboard and its related APIs is a much better tool for what you are trying to achieve.

[bvetterdays (roman)]

Thank you so much!! Can confirm I haven’t seen the issue pop up in the last few days.

@BrightYellowElephant

As a side effect of the fix, you may start seeing more 500s in your response so please make sure your application is able to handle that gracefully.

Of course, any good web dev knows to handle the occassional HTTP 500 error from Roblox.

@BrightYellowElephant

However, I would like to point out that catalog-api is not built for fetching moderation status as a use case. If you are monitoring your own creations, the creator dashboard and its related APIs is a much better tool for what you are trying to achieve.

Yup, understood. However my use case is a little different; I’m checking the moderation status of other creators’ assets. It’s a long story, but essentially myself and some other users report rule-breaking items through multiple avenues and then add them to my tracking system so we can get notified when they’re deleted/appealed and reinstated incorrectly.

Thanks so much for this quick fix, it truly means a lot. I was previously double/triple checking an item’s moderation status through multiple catalog endpoints just to ensure it was deleted/restored before sending the notification now I can finally remove this logic!