Fashion Product Data API: Search Clothing by Brand, Color, Size, and Gender Across Retailers

A fashion product data API lets an app search clothing from many retailers through one structured request, instead of connecting to each merchant's feed separately. For fashion that matters more than in most categories, because shoppers rarely start with a product name. They start with a brand, a color, a size, and a department, and they expect every result to respect all four.

Affiliate.com normalizes product data from more than 30 networks, tens of thousands of merchant programs, and over a billion products into one searchable structure. Normalizing means records from different merchants land in the same fields, so a filter written once works across retailers. It does not mean every value is identical. This article walks through each of the four filters using live results, shows what each one returns in practice, and covers the cleanup an app still has to do.

What "Across Retailers" Looks Like in Practice

To see the spread, we ran one search for in-stock, USD-priced women's linen shirts that are white or ivory, priced between 30 and 120. It matched 1,257 records from about 30 merchants. Requesting the merchant facet, which returns a count per merchant, showed how those records were distributed:

The remaining merchants, from Loft and Banana Republic to Grailed and Ralph Lauren, accounted for the rest. The merchant counts add up to exactly 1,257. Facets are limited to three options: network, merchant, and final price. They cannot count by brand or color, so those counts have to come from the results themselves.

Keyword search is also broad. A few records came from merchants you would not expect for linen shirts. That is the main reason attribute filters matter: they turn a loose keyword match into a defined result. The multi-retailer product search approach depends on that combination of a keyword and filters.

The Four Filters, One at a Time

Brand, color, size, and gender are all searchable product attributes. Each one behaves a little differently on real clothing records.

Brand

Brand is the most natural filter and the least complete. Matching with LIKE finds a label such as Levi's with the value "Levi", and a double pipe lets one request match several brands at once, for example "Nike||adidas".

The gap is that retailers' own labels are not always filled in. In our results, several Gap records had no brand value at all, while another Gap record in the same set had the brand "Gap". A brand filter alone would have missed the first group. For a retailer's own label, pair the brand filter with a merchant filter, or filter by merchant ID instead. The brand filtering guide covers curation patterns in more detail.

Color

Color is free text written by each merchant, not a standard palette. In one result set the values included "White", "WHITE", "Optic White", "Chakra Red", "Aqua/White", "Blue & White Stripe", and "IVORY". Even the casing varies for the same color.

Matching "white" with LIKE is partial, so it also returned a blue and white striped tunic and an aqua and white shirt. Whether that counts as a match depends on the app. A shopper browsing "white shirts" probably wants solid white first.

A practical approach is to keep the merchant's original color text for display and add an app-side color family, such as white, blue, or red, for filtering. Build the mapping once and apply it to incoming records.

Size

Size is where clothing data is most varied. Across one set of results we saw "XS", "XXL", "L", "Small", "Large", "S/M", a lowercase "m", plain numbers such as "2" and "12", and a range, "6-8". Numeric sizes from different regions do not mean the same thing, so a "12" at one retailer is not necessarily a "12" at another.

Two behaviors are worth knowing:

• Size matching works on whole values within the text, not the exact string. Searching for size "M" returned records sized "M", a lowercase "m", and "S/M". Exact match and LIKE returned the same 4,404 records in our test. If you filter on "M", expect combined sizes to come back too.
• Jeans lose the second measurement. Levi's 501 records at one merchant had names like "32 32" for waist and inseam, but the size field held only "32". Records with different inseams all showed the same size. For bottoms sold by waist and length, the product name carries information the size field does not.

Also, some merchants do not put the size in the product name at all. One retailer listed a pair of jeans as "Green Stf" with no size in the name, even though each size is a separate record. The size is only in the size field and the barcode.

Gender

Gender is the cleanest of the four. Values were "Women" in most records and "women" in some, and matching is not case-sensitive: searching for "women" and "Women" at a merchant that uses lowercase returned the same 374 records both times. You do not need to worry about casing in the query. Still, standardize the value in your own interface so the app never displays both versions.

Check how your target retailers label men's, women's, unisex, and children's items on a sample before building department pages, because we only confirmed the women's and men's cases.

Layering the Filters Into One Request

The filters are most useful together. The layered filtering approach starts broad and narrows with each field. Here is the request behind the 1,257-record result:

{
"search": [
{ "field": "any", "value": "linen shirt", "operator": "LIKE" },
{ "field": "gender", "value": "women", "operator": "LIKE" },
{ "field": "color", "value": "white||ivory", "operator": "LIKE" },
{ "field": "availability", "value": "InStock", "operator": "=" },
{ "field": "currency", "value": "USD", "operator": "=" },
{ "field": "final_price", "value": "30", "operator": ">=" },
{ "field": "final_price", "value": "120", "operator": "<=" }
],
"fields": ["name", "brand", "color", "size", "final_price", "regular_price", "currency", "availability", "barcode", "merchant.name"],
"facets": ["merchant", "network"],
"sort_by": "final_price",
"sort_order": "asc",
"per_page": 24
}

Every line earns its place:

• Keyword and gender define the department and the item.
• Color uses the double pipe so one request covers both shades.
• Availability keeps unavailable items out of the results.
• Currency is the line most often forgotten. When we removed it, the same search returned 2,426 records, and the price range of 30 to 120 was applied to a mix of USD, AUD, and GBP values. A shirt priced at 111.20 AUD passed the filter next to a shirt priced at 74.99 USD. Always filter by currency before filtering by price.
• Fields limits the response to what the screen needs, which reduces payload.
• Sort and page size control ordering and paging.

Broad searches report a total capped at 10,000 by default. When a result set is larger than that, the REST API supports exact totals and a cursor for deeper paging.

One Garment, Many Retailers: A Real Example

Clothing does not come with a single product ID shared across retailers, but barcodes do the same job for items sold by several merchants. We searched five Levi's 501 barcodes and got 18 records from six merchants, because the same barcode appeared at multiple retailers under different names.

For one barcode, a men's 501 in green, size 30 by 32, the offers on October 5, 2026 were:

Five different names, one barcode. A name-based match would have missed most of these, and one of them contains no size at all.

Adding barcode deduplication collapsed the 18 records to 5, one per barcode. With results sorted by final price ascending, the record kept for each barcode was the lowest-priced one. The order of the sort therefore decides which offer survives, so sort first.

There is a catch for apparel. Records without a barcode are treated as sharing the same empty value. In our linen shirt test, two ASOS records had no barcode, and deduplication kept only one of them. If you deduplicate on barcode, you may quietly hide every barcode-less item after the first. Either leave deduplication off for merchants that do not supply barcodes, or deduplicate in your own code.

Finally, each size has its own barcode, so deduplication compares exact size records, not whole styles. Grouping sizes into one product page is still the app's work. Prices here are a snapshot and can change at any time, so always read them from live results.

What the App Still Has to Clean Up

Normalized does not mean uniform. Plan for these on ingestion:

• Casing and wording: standardize colors, sizes, gender, and condition so filter chips do not duplicate.
• Color families: map merchant color text to a small set for filtering, and keep the original for display.
• Size formats: convert sizes to one system where you can, and keep region and fit information when you cannot.
• Missing brands: fall back to the merchant when a brand is empty.
• Empty fields: treat missing color, size, or material as unknown, not as an error.
• Currency: store the currency with every price and never compare across currencies.

A Build Checklist

• Filter on availability, currency, gender, and the keyword before anything else.
• Use LIKE for text fields and the double pipe for alternatives.
• Pair the brand filter with a merchant filter for retailers' own labels.
• Test size filters against real results, especially for combined sizes and jeans.
• Sort by final price before deduplicating, and treat barcode-less records separately.
• Request only the fields each screen needs.
• Confirm prices, stock, and field coverage in the live Query Builder or API before launch. Both change often, and nothing here guarantees a price or availability.

Try It in the Query Builder

The quickest way to see all of this is to open the Affiliate.com Query Builder, search a clothing keyword, and add gender, color, size, and brand one at a time. Watch how the count changes after each filter, then add the currency filter before the price range. Once the results look right, the same structure becomes your API request, and the full set of filters is documented for the next step.