Foot Locker Product Scraper

Scrape Footlocker.com, Footlocker.ca, and Footlocker.com.au — live sneaker, apparel, and accessory listings across all 3 storefronts. Search by keyword, browse by department/category or brand, or fetch full product detail (price, rating, colors, sizes, images) by URL. No login required.

What this actor does

• Four modes: search, browseByCategory, browseByBrand, productDetail
• 3 markets: United States (footlocker.com), Canada (footlocker.ca), Australia (footlocker.com.au) — identical URL/data structure across all 3
• 9 department/category shortcuts — Men's, Women's, and Kids' shoes, clothing, and accessories
• 28 curated brands — Nike, Jordan, adidas, New Balance, ASICS, and more
• Filters: price range, minimum rating, on-sale-only, new-arrivals-only
• Sort: relevance, price (low/high), new arrivals, name/brand (A-Z), rating, most reviewed — price/new-arrivals/name/brand are genuinely ranked by Foot Locker's own server across the full catalog for search/browseByBrand (not just a re-shuffle of one fetched page)
• Full product detail: all color variants, description, image, plus gender/category, style code, width, and in-stock sizes parsed from the page's own product-state data
• Empty fields are omitted

Output per product

• sku — Foot Locker's product SKU
• productName, brandName
• price — current selling price (local currency)
• originalPrice, percentOff, onSale
• averageRating (1–5), reviewCount
• gender (Men's / Women's / Kids')
• color, availableColors[] (product detail only)
• description (product detail only)
• productCategory, productSubCategory (product detail only — e.g. Shoes / Casual Sneakers)
• styleCode, width (product detail only)
• isNewProduct, isSaleProduct (product detail only)
• availableSizes[] — in-stock sizes only (product detail only)
• inStock, availability
• imageUrl
• productUrl
• recordType: "product", scrapedAt

Input

Field	Type	Default	Description
market	string	US	US (footlocker.com) / CA (footlocker.ca) / AU (footlocker.com.au)
mode	string	search	search / browseByCategory / browseByBrand / productDetail
searchQuery	string	running shoes	Free-text keyword search (mode=search)
category	string	mens-shoes	Department + category to browse (mode=browseByCategory)
brand	string	Nike	Brand to browse (mode=browseByBrand)
productUrls	array	–	Foot Locker product page URLs from any of the 3 markets (mode=productDetail)
minPrice / maxPrice	int	–	Price range in local currency
minRating	int	–	Drop products rated below this (1–5)
onSaleOnly	bool	false	Only emit discounted products (server-side for search/browseByBrand)
newArrivalsOnly	bool	false	Only emit new-arrival products (search/browseByBrand only)
sortBy	string	relevance	Result sort order — see FAQ for which options are server-ranked vs. client-side
maxItems	int	20	Hard cap (1–300) — see FAQ for a real per-query ceiling of ~48 products

Example: search with price and rating filters

{
  "mode": "search",
  "searchQuery": "Jordan 1",
  "minPrice": 80,
  "maxPrice": 250,
  "minRating": 4,
  "maxItems": 30
}

Example: browse a category, on sale only

{
  "mode": "browseByCategory",
  "category": "womens-shoes",
  "onSaleOnly": true,
  "sortBy": "priceLowToHigh",
  "maxItems": 50
}

Example: browse a brand

{
  "mode": "browseByBrand",
  "brand": "New Balance",
  "maxItems": 30
}

Example: product detail by URL

{
  "mode": "productDetail",
  "productUrls": [
    "https://www.footlocker.com/product/asics-gel-1130-mens/1A906001.html"
  ]
}

Example: browse Canada, cheapest genuinely-cheapest-first

{
  "mode": "browseByBrand",
  "market": "CA",
  "brand": "Nike",
  "sortBy": "priceLowToHigh",
  "maxItems": 30
}

priceLowToHigh here is ranked by Foot Locker's own server across Nike's entire catalog — not just re-sorted among whatever one page happened to return.

Example: new arrivals only, in the US

{
  "mode": "search",
  "searchQuery": "running shoes",
  "newArrivalsOnly": true,
  "sortBy": "newArrivals",
  "maxItems": 30
}

Use cases

• Price monitoring — track Foot Locker sale prices and discount depth over time
• Assortment research — see which brands and models dominate each category
• Sneaker release tracking — monitor new arrivals and restocks by brand
• Review analytics — pull rating and review-count trends by brand or shoe model
• Competitive intelligence — compare footwear pricing/ratings against other retailers

FAQ

Is this affiliated with Foot Locker? No — this is an independent, third-party actor that reads Foot Locker's public website. It is not endorsed by or affiliated with Foot Locker, Inc.

Do I need a Foot Locker account or cookies? No. All modes work against publicly browsable pages — no login required.

How is brandName determined on listing records? Foot Locker's search/category cards don't expose brand as a separate field, only inside the product name (e.g. "ASICS® GEL-1130"). The actor matches the product name against a curated list of known Foot Locker brands. On productDetail, brand comes directly from Foot Locker's own structured product data instead.

Why does browseByBrand use search internally? Foot Locker doesn't expose a stable, crawlable brand-only listing URL, so the actor searches the brand name plus "shoes" (a bare brand-name query like "New Balance" reliably returns an empty product grid on Foot Locker's own search) and keeps only records whose brandName matches.

What counts as "on sale"? Any product where Foot Locker displays a discounted price below the original listed price. For search/browseByBrand, onSaleOnly is also applied as a genuine server-side catalog filter before fetching, in addition to the client-side check — the client-side check is the final authority, so a record is only ever emitted with onSale: true if its card actually shows a markdown. Note this means onSaleOnly combined with newArrivalsOnly can legitimately return 0 records even when Foot Locker reports a non-zero match count server-side: Foot Locker's discount-eligibility facet is broader than "currently showing a markdown" (it also includes items only eligible for checkout promo codes), and the intersection with new arrivals is often small.

Which sortBy options are truly catalog-wide vs. just re-sorting one page? For search and browseByBrand, priceLowToHigh, priceHighToLow, newArrivals, nameAtoZ, and brandAtoZ are passed straight to Foot Locker's own search ranking and reflect the full matching catalog. ratingHighToLow and mostReviewed have no working server-side equivalent on Foot Locker's search (confirmed live — several plausible rating-sort codes were tested and all silently fall back to relevance order), so those two remain a client-side re-sort of the fetched page only. For browseByCategory, every sortBy option is client-side only — Foot Locker's category pages ignore both the sort-suffix search syntax and a ?sort= query parameter (confirmed live).

Why is newArrivalsOnly scoped to search/browseByBrand only? Foot Locker's category pages (/category/<dept>/<type>.html) don't support the same query-based facet syntax that search does; there's no confirmed working way to filter new arrivals server-side on browseByCategory, and there's no reliable per-item "new" signal on category listing cards to filter client-side either. Use mode=search with a category-like keyword (e.g. "running shoes") plus newArrivalsOnly: true instead.

What markets are supported? United States (footlocker.com), Canada (footlocker.ca), and Australia (footlocker.com.au) — all three use the identical page structure. footlocker.eu is a thin redirect page with no real storefront and is not supported. Note: Foot Locker Australia's own search engine is inconsistent with single-word queries (e.g. "shoes" or "nike" alone can return 0 results) — use multi-word phrases (e.g. "nike shoes", "running sneakers") for reliable AU search results; browseByCategory and browseByBrand are unaffected.

What does productDetail enrichment add beyond the basic fields? Foot Locker product pages embed a second data block (their internal page-state snapshot) alongside the standard structured product data. The actor parses it to add gender, productCategory/productSubCategory, styleCode, width, isNewProduct, isSaleProduct, and availableSizes (in-stock sizes only — impossible to derive from the standard structured data, which has no size information at all). This is purely additive: if that data block is ever missing or malformed on a given page, the standard fields still populate exactly as before with no missing/broken output. Release date and related/cross-sell products were investigated but are not present in either data source, so they're not included.

How fresh is the data? Real-time — every run loads the live Foot Locker page.

Why do I get at most ~48 products from a single search/browseByCategory/browseByBrand run, even with a higher maxItems? Foot Locker's own listing pages serve a single fixed-size page of roughly 48 products per query/category/brand, and there's no working server-side pagination for non-browser clients — every page-number/page-size variant Foot Locker's own site uses returns that identical first set of products. maxItems caps how many of that page's products are emitted (useful for narrowing down), but it cannot pull in more than Foot Locker itself returns for that one query. To collect more products, run additional queries — a more specific keyword, a different category, or a different brand — and merge the results, or use productDetail with a list of specific URLs.