Catalog & Catalog API not returning all valid Classic Clothing when Searched..

Example Group: IRF | Admissions - Roblox
The API Catalog Search Call, for the Above group – https://catalog.roblox.com/v2/search/items/details?AssetTypeIds=11&AssetTypeIds=12&CreatorType=2&CreatorTargetId=3052496&IncludeNotForSale=true&limit=120&sortOrder=Desc

Going to the Physical Catalog Page for said group, from anywhere (Physical group store, or item on catalog) for a split second pops up a red “Errors Exist in Filter tab” Notice, and immediately closes it… (https://gyazo.com/3068eff1c1952627eaec878653fdb2e0)

This Image, is currently what Catalog Shows when I go to it, and set view unavailable items to true…

This Gyazo Gif is what shows up when I run the API Call..
https://gyazo.com/9959b57372cea6de4914a4aef489d248


This Video, Has Multiple different tabs, with the first 2 primary ones, showcasing that Marketplace & API only see 5 Clothing items present… But Every Other Tab afterwards on the video, are Valid Clothing items, made and uploaded to the group..
TURN ON SUBTITLES WHEN WATCHING THE VIDEO

Expected behavior

In this Specific Case, when Opening up Catalog & Setting “IncludeNotForSale” to true, it should show all the Clothing items available on the group, not just 5, even if everything is offsale…

Granted, this is not just a single group issue, this is happening to multiple groups, but not reported…

Thanks for raising this, a member of our team is looking into this. When did this first start happening for you?

I have not tried to look through the catalog to Archive the uniforms for a few years, unfortunately so I have no idea when this first fully started happening, but For me, this started a few days ago when i made a roadmap for my plans in the Uniform section of the Roleplay Community, that the group used as an example belongs to.. as I was planning to make a physical archive of all of the Uniforms from our Many many groups we have had over the years, with the catalog links and all that..

Oh also, while on the topic of catalog/clothing API, this next thing im saying isnt necessarily a Bug report but a Suggestion..

Ive seen multiple times where clothing from the groups I Manage get stolen and reuploaded to a random group, I dont know how long ago it was removed, but is it possible to re-work the creator identification for the clothing, even if not on Catalog but on the API

Previously a Long time ago, Clothing when uploaded would show who Uploaded them, even when uploaded to a Community…
But at some point when the AssetContent started being Uploaded to the Communities instead of the Individual Creator, it just entirely switched to created by: {Community Name}

(Reason behind this suggestion) - Ive got one group i have to look into because they blatantly ripped our clothing from one of our many sub-groups but I Genuinely dont know if it was the original creator who did that or not, because I have no contact with them anymore, and I cant find what the Username of the original Creator is… because it was uploaded 2 years ago, and, everything just shows as created by {Community Name}

Pls refer to marketplace’s most recent announcement in terms of policy updates when it comes to publishing 2D assets to the marketplace made in March 2026 this year.

Since we are way past the March 20th deadline, if your account is not in compliance, what most likely happened was the various previously available 2D clothing you uploaded got delisted and taken off sale. It will not even show up if you apply “Show unavailable” filter on marketplace.

You will have to follow the instructions on that post to make sure your account is in compliance with the 2D publishing requirements, before going back and publish all your 2D items again.

It seems like you are using some plugin to browse the marketplace. The store’s view and your calls to catalog-api is consistent with expectations of how our product is supposed to work. However, the plugin may be calling inventory-api that will continue to show your group or creator still owns those 2D assets. This is because the items are being delisted, which means ownership is not affected, but it won’t show up in the marketplace at all.

You mean the March Deadline. Which then got pushed to July 31st, and Has Yet to actually Occur? The Extension I have, Only edits the page to show marketplace items that have been Archived, Or Moderated… its a Public Chrome Extension…

Your answer saying its expected, if its a valid catalog link, then Logically speaking, the item should show up,
the tab literally says Show UNAVAILABLE Items, but at the same time, the url appends “IncludeItemsNotForSale”

Thats just false information at this point.. Those Catalog Items are 100 percent valid links, and all of those ones in the video, Minus the ones that showed on a custom page.. they are valid you cant just say its expected behavior when…

  1. The Catalog update mentioned, the end results of “delisting” all clothing uploaded that doesnt meet the requirements, Has YET to occur. Almost a month after the set date…
  2. The links return properly to the marketplace, and are all valid marketplace items, Extension or not…
  3. I could care less if its “intended”, if ShowUnavailable is set to true, it should show all Items minus Archived & Moderated… not hiding them entirely..
  4. Oh and by the way the kicker, your logic is flawed, the 5 clothing items that actually show on the group, are the exact same case as all Other items… but they are present on API & Catalog…

You can say this is an intended feature, But from everything ive seen, intended or not… that is really just a Massive Bug in Marketplace & Marketplace API

P.S. the erorr in filter has existed prior to my adding the Extension to my chrome.

there are multiple bugs in the Marketplace and instead of looking into whats actually going on. You are tying this into the recent Marketplace Changes, but i know for a fact that these bugs Have existed for LONGER than the marketplace Update has been in the works for…

This isnt intended to be disrespectful or Rude towards you, but this is my honest response…