Get ASOS data with one API

id is the product as ASOS links to it, and it is colour-level: 210791038 is the yellow colourway of that dress. product_code ("156679606") is the internal style code. sku is per size, so the XS is "156679614", and each size also has its own 13-digit ean ("8447489469461") and its own numeric variant id (210791040). Fetch by id, match against a warehouse feed by sku or ean.

Measured on 2026-08-27: COM and GB return GBP, US returns USD, DE and FR return EUR. ROW is offered in the enum but ASOS answered HTTP 400 and the call came back as INVALID_PARAM, so treat it as unusable. The default is COM. The store changes the assortment too, not just the money: the same query reported 21,417 results on GB and 100 on FR.

Because that product is not sold in the US store, so the live per-store price and stock lookup found nothing and the response fell back to the price embedded in the product page. The tell is meta.stockprice: it read "unavailable" on that call, against "v4_matched_5" for the same product with store=COM. When you request a market, check that field before trusting price.currency.

Only when is_marked_down is true. On the product action a full-price item returns previous_value equal to current_value (27.99 and 27.99), while search returns previous_value null for the same item. On a marked-down item the actions agree: 210882523 came back as current 17.99, previous 29.99, is_marked_down true. So branch on is_marked_down rather than on whether previous_value is present.

variants[] carries in_stock per size, plus is_low_in_stock and is_restocking_soon. On product 210791038 the XS and S variants were in_stock true while M - UK 10 was false, even though the product-level in_stock was true. Product-level in_stock means at least one size is available, so read the variant rows whenever size matters.

It means a partner brand fulfils the order rather than ASOS shipping from its own stock. The Bershka dress returned seller {"id": "BRKAFS", "description": "BERSHKA UK LTD"} on every size, while a Never Fully Dressed item on the US store returned seller null on its variants. The id is a short alphanumeric partner code, not a numeric account id.

You get an empty result set, not an error. Brand names are resolved to ASOS facet ids before the search runs, so a misspelling like 'Nikeee' resolved to nothing and the call returned ok true with total 0 and no products. Call the filters action first to list the brand, colour and size facets a query actually supports.

The product action returns the garment as a whole and hangs colour information off each variant row instead, so the top-level colour_way_id is null while every variant carries its own (210791039 on that dress). Search rows do fill the top-level field, because a search row is one colourway. If you need it from the product action, read variants[0].colour_way_id.

ASOS API is a ReefAPI endpoint group for asos It returns live JSON through POST requests under /asos/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. ASOS calls use the same shared credit balance as every other ReefAPI engine.

No login to ASOS is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.

ASOS actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call asos actions with the same key, credit pool and JSON envelope used by normal REST requests.