Just a note and somewhat of a warning that this is a very detailed bug report, and those who are unaware of how the catalog API works should not bother reading much of what’s below. 
API AFFECTED: https://catalog.roblox.com/v1/search/items
Sometime in the past few days, an essential catalog API (linked above) used across the majority of the web catalog and in some of Roblox’s most popular games has had some of it’s search params completely broken. The issue solely affects users trying to search the catalog, and games such as PLS DONATE which retrieve their users’ on-sale clothing assets via this same API. There are 2 parameters which are completely broken, both of which are listed and described in detail below.
1. includeNotForSale
Surprisingly enough, this parameter has actually been broken for months now, if not years. The issue with it is, when it’s toggled off (via clicking the Hide option under Unavailable Items in the catalog filter), it instantly eliminates all shirts, t-shirts and pants from the search results and will only return on-sale UGC accessories. For example, take a look at the screenshot below. Currently, I have one UGC hat accessory and one t-shirt on sale, as well as multiple other shirts, t-shirts and pants that are off sale. In the image below, the search results returned by the catalog with the Unavailable Items option set to Show returns what it should; all of my assets I have created, regardless of whether they are on-sale (‘available’) or off-sale (‘unavailable’).
API used in this screenshot: https://catalog.roblox.com/v1/search/items?category=All&creatorName=bvetterdays&includeNotForSale=true&limit=120&salesTypeFilter=1&sortType=3
But then, when I re-search with those same parameters, except with the Unavailable Items option set to Hide, we see that as explained above, it instantly eliminates all shirts, t-shirts and pants from the results.
API used in this screenshot: https://catalog.roblox.com/v1/search/items?category=All&creatorName=bvetterdays&includeNotForSale=false&limit=120&salesTypeFilter=1&sortType=3
This is obviously unintended behavior and it’s a nuisance for both users and developers alike to run into these issues with these APIs, and have to figure out ways around them. Obviously, the only workaround to this bug is having the Unavailable Items option set to Show (the includeNotForSale param of the API request as true). For the average user browsing the catalog, this means they could have to scroll through multiple unavailable catalog assets even if they just wanted to see the available ones. And developers using this API are worse off; they are forced to set the includeNotForSale parameter to true in their API request, just to include non-accessory assets, and then have to make more unnecessary requests to get the data of each asset ID the API returns and manually check whether each one is on sale or not. This is the case for games like PLS DONATE which heavily rely on this API (and are currently experiencing issues retrieving on-sale clothing assets because of it).
2. minPrice
Unlike the previous parameter, this one ceased to work sometime within the past few days and is the main contributing factor as to why this API has become almost unusable. Previously, the minPrice parameter basically cancelled out the includeNotForSale one, and served as a workaround to it’s flaws; allowing you to exclude items that were off-sale from being returned. To put it simply; a few days ago the includeNotForSale parameter essentially served as includeShirtsAndTShirtsAndPants instead, and the minPrice parameter would basically do what includeNotForSale was supposed to (when set to 1, of course).
Now, including the minPrice parameter in requests to the API in question at ALL eliminates all shirts, t-shirts and pants from being included in the returned results, similarly to the issue with the includeNotForSale parameter.
Edit: I dug a little deeper into this and found that this bug only affects catalog items (excluding UGC accessories) that have been created or updated within the past few days, since it began occurring. It affects newly created assets differently to recently updated ones. Here’s how:
Newly Created Items
Catalog items that were created since this bug became prevelant are completely excluded from the results returned by the API, regardless of price, assuming the minPrice parameter of the request is 1.
Recently Updated Items
Catalog items that had their price changed since this bug became prevelant (but were created before it did) are not excluded from the results, but instead filtered as their old price rather than their new/current one.
As an example, let’s say I created a shirt and put it on sale for 10 Robux one month ago. In this case, this API request (with minPrice set to 10) would return the shirt in it’s results, because it meets all of these conditions:
- It’s price is above the minPrice parameter; 10 Robux.
- It was created and had it’s price set before this bug began occurring.
However, if I changed the price of that same shirt to 5 Robux right now, and made the same API request described above, keeping the minPrice parameter as 10, the results would still include the shirt even though it’s price no longer exceeds the minPrice parameter. It seems items like these are having their price detected by the API as what they were before the bug began, rather than what they were most recently updated to after it began.
API link with minPrice set to 1 (does not return any shirts, t-shirts or pants; broken): https://catalog.roblox.com/v1/search/items?category=All&creatorName=bvetterdays&includeNotForSale=true&limit=120&salesTypeFilter=1&sortType=3&minPrice=1
Same API but excluding the minPrice parameter altogether (returns expected results; works): https://catalog.roblox.com/v1/search/items?category=All&creatorName=bvetterdays&includeNotForSale=true&limit=120&salesTypeFilter=1&sortType=3
I also came across this separate bug report, regarding UGC creators being affected by the issue with parameter 1.
This is quite a major issue on Roblox’s end - us developers have dealt with the includeNotForSale parameter not working up until now, but as we used the minPrice parameter as a workaround, there’s nothing else we can do now other than make broad requests to the API and check if (possibly hundreds of) assets are on or off sale individually and manually, which is unnecessarily consuming our resources.
Finally, going to CC an engineer who I think could help with this issue (based on past relations) due to it’s significance: @YungAK_365
