ASOS Products Scraper

Product listings from ASOS search and categories, across 8 storefronts — via the site's own public JSON API. No HTML parsing, so nothing here breaks on a redesign.

Returns name, brand, price, was-price, the EU 30-day lowest price, colour, product type, images and stock signals.

Input

{
  "mode": "search",
  "store": "uk",
  "keywords": ["running shoes", "denim jacket"],
  "sortBy": "priceAsc",
  "pageLimit": 200,
  "maxPages": 3
}

Or list a category by ID (a category URL containing ?cid= works too):

{ "mode": "category", "store": "de", "categoryIds": ["4209"] }

Stores

uk us de fr it es nl au — each with its own currency, language and catalogue. The same query returns 12,150 items on UK and 8,035 on US, so the store is a real choice, not a display setting.

The API needs a matching store/currency/language/country set and rejects a partial one, so only combinations that were called and confirmed are offered.

What you get

{
  "recordType": "PRODUCT",
  "productId": 206644707,
  "productUrl": "https://www.asos.com/on/on-cloudrunner-3-...",
  "name": "ON Cloudrunner 3 running trainers in green",
  "brandName": "On",
  "currency": "GBP",
  "price": 89.99, "previousPrice": 140.0,
  "lowestPriceInLast30Days": 98.0,
  "isMarkedDown": true,
  "colour": "GREEN", "productType": "Product"
}

lowestPriceInLast30Days is ASOS's own EU price-transparency figure — the number a "was £140" claim is actually measured against. It is published on the listing endpoint, so you get it without a per-product fetch.

Known limits — read these before you rely on the output

pageLimit above 200 is refused up front. ASOS's ceiling is 200 and it clamps silently — asking for 500 returns 200 rows with HTTP 200 and no warning of any kind. Bisected: 199 → 199, 200 → 200, 201 → 200. This is the one place the API is not explicit, so the actor refuses the value rather than letting you believe you asked for more. Every summary reports pageLimitRequested beside pageLimitUsed.

ASOS fuzzy-matches an unmatched query rather than returning nothing — but it is honest about the size. itemCount drops from 12,150 for "shoes" to 34 and 13 for two different nonsense strings, and the rows that come back have internal code-like names. Both signals are surfaced: upstreamItemCount is passed through, and titleMatchRate measures how many returned products actually mention a query token (name, brand, product type). lowRelevanceWarning flags a run below 20%. Rows are never dropped for it.

Everything else about this API is honest, which is worth stating. A bad sort, a bad store and a missing query each earn an HTTP 400 whose body names the offending parameter. Past the last page you get 200 with an empty products array while itemCount still reports the true total. Offset paging is genuine: offsets 0 and 48 share zero ids, and offset 0 fetched twice is identical. Most of this actor's validation exists to fail sooner with a better message, not to compensate for lies.

previousPrice is absent on full-price items. It was present on 49 of 60 in testing — items with no markdown genuinely have none. It is left null rather than echoing price.

Technical

GET https://www.asos.com/api/product/search/v2/ — the same endpoint the web client uses, anonymously: no key, no token, no signature. The mobile host api.asos.com rejects the identical call with

400 "The Language field is required"

No WAF: 5/5 TLS profiles returned 200.

robots.txt was checked on the API path itself, not just the apex: /api/product/search/v2/ is ALLOWED, and the User-agent: * group disallows only a handful of unrelated paths.

Full recon trail is in CRAWLING_METHOD.md.