Department store data looks simple until you try to store it. One product page is not one product - it is a family of variants with different sizes, colours, prices and stock, sitting under promotions that apply at the basket rather than the item.
Kohl’s is a large US department store chain spanning apparel, home, beauty and footwear, with both national and exclusive own brands. The Kohl’s API is compact - six endpoints - but covers the retail intelligence surface properly.
The endpoints
/product-search - keyword search across the catalog with pricing and images.
/product-details - the full record for one product, including variants, pricing and attributes.
/product-reviews - customer reviews with ratings.
/product-qa - the customer questions and answers section, which most retail APIs skip entirely.
/categories - the category taxonomy.
/stores - store locations.
The two fields that cause problems
Variants. A shirt is one product page with sizes and colours underneath, each with its own availability and sometimes its own price. Whether you treat the page or the variant as your unit determines whether your stock analysis means anything. Model the variant as the row and the product as the parent; the reverse is very hard to undo later.
Promotional structure. US department stores run layered discounting: a list price, a sale price, a percentage-off event, and often a coupon on top. What a shopper pays is the result of the stack, not any single field. If you store one number as “the price”, you will be unable to answer why it changed.
Kohl’s Cash is the specific complication here, and it is worth understanding rather than ignoring. It is earned on a purchase and spent on a later one, which makes it a forward discount rather than a present one. A straight price comparison against a competitor that does not run a loyalty currency is not comparing the same thing.
Q&A is underrated
/product-qa is unusual and worth using.
Reviews tell you what buyers thought afterwards. Questions tell you what buyers could not determine beforehand, which is a direct read on where the product page fails. Recurring questions about sizing, materials, dimensions or compatibility are gaps in the listing.
For a retailer that is a merchandising signal. For a competitor it is free research on what shoppers in a category actually care about. For anyone training a product-understanding model it is labelled data on which attributes matter enough to ask about.
Store data
/stores matters more than it looks. Department store retail is omnichannel: buy online pick up in store, ship from store, and returns in store. Store location data is what connects an online catalog to physical footprint.
Combined with the category tree, it supports trade-area analysis, competitive proximity work, and any feature that needs to know where inventory physically sits.
What people build
Price and promotion monitoring. Track list, sale and event pricing over time. The promotional layer is where the signal is - the frequency and depth of events says more about a category than the list price does.
Assortment analysis. What is carried, in which categories, at what price points, and how that shifts seasonally. Kohl’s exclusive brands versus national brands is a useful axis.
Review mining. Ratings distribution by category, sentiment on specific attributes, and comparison against the same product at other retailers.
Competitive benchmarking. Same product, multiple retailers, tracked over time. Pair with the Klarna Ecom API for cross-retailer price history rather than doing the joins yourself.
Retail media and category research. Category structure and product metadata for market sizing.
Practical notes
Snapshot on a schedule and store what you get. Retail APIs return the current state, and promotional history is only obtainable by having collected it. A price series with gaps around sale events is worse than useless, because the gaps are exactly the interesting parts.
Store the full price stack, not the computed final number. You can always recompute; you cannot decompose.
Product IDs change more often than you would like in apparel, as lines are discontinued and reintroduced. Match on identifiers where possible, but expect to need fuzzy matching on brand plus name plus attributes for longitudinal work.
Seasonality dominates apparel. Comparing October to July tells you about the calendar, not the market.
Related APIs
For other US and global retail, see the IKEA Pro API for furniture, the H&M API for fashion, or the Sephora API for beauty. For cross-retailer price comparison, the Klarna Ecom API covers many merchants at once. Browse the ecommerce data hub.
Disclaimer
Happy Endpoint is not affiliated with, endorsed by, or sponsored by Kohl’s. All data is collected from publicly available sources.
