How do you track StockX sneaker prices via API?

The obvious plan is to read the big numbers off the product page and compute a spread. On the Jordan 4 Retro Bred Reimagined we measured lowest_ask 204 and highest_bid 247 in the US market on the same request. A bid above an ask is impossible inside one order book - it would have matched. Those two figures are the best ask and the best bid taken across all 26 sizes, and they belong to different sizes. Any spread, liquidity or arbitrage number built on the product-level pair is measuring nothing.

The second trap is currency. StockX will happily price the same product in EUR, and it looks like a straight conversion until you check the depth. Switching from US/USD to DE/EUR moved lowest_ask from 204 to 167 and the ask count from 1,499 to 1,404 - a different book, not a converted one. But sales_last_72h stayed at 62 and sales_count_90d stayed at 1,976 in both, because the volume figures are global. Half the market block localises and half does not, and nothing in the response labels which half is which.

The third only shows up on fast-moving products. Ask for a 90-day price history on a shoe that sells 1,976 pairs a quarter and the sales feed runs out of room before it runs out of days.

Use variants[] for anything that has to be right. Each entry carries variant_id, size, lowest_ask, highest_bid and last_sale for that size alone, and inside a size the book behaves: size 3.5 came back with ask 220 against bid 145 in USD. The variant_id is stable across markets - the same UUID appeared in both the US and the German response - so it is a safe primary key for a price-history table.

market and currency are two separate levers and it is worth knowing which fields each one moves. In our side-by-side, market/currency changed lowest_ask (204 to 167), highest_bid (247 to 181), last_sale (213 to 183), number_of_asks (1,499 to 1,404), avg_price_90d (222 to 190) and avg_price_annual (237 to 204). They did not change number_of_bids (262), sales_last_72h (62), sales_count_90d (1,976) or volatility (0.1228 against 0.1224, the same series measured in different units).

One field to treat carefully: retail_price does not convert. It came back as 215 in the USD response and 215 in the EUR response. price_premium is computed from it, which is why the same shoe reads price_premium -0.0093 in the US and -0.1488 in Germany - the German figure is a EUR last sale divided by a USD retail. If you compare premium across markets, recompute it yourself against a converted retail. We would rather tell you that than let you find it in a dashboard.

price_history exposes the sampling limit instead of hiding it, in a field called window_complete. We asked for window '90d', bucket 'month' on the whole product: it sampled 400 sales, every one of them landed in the current month, and it returned one series point with window_complete false. The identical request scoped to size 10 sampled 310 sales, covered four months (2026-05 through 2026-08) and returned window_complete true. On a high-volume product, asking for one size gives you more history than asking for the whole product. Check window_complete before you draw a trend line.

null is used where a figure genuinely does not exist rather than being collapsed to zero. avg_price_72h came back null while sales_count_72h read 62, and in the German market express_next_day returned count 0 with lowest_ask null. A zero there would read as a free next-day ask.

Invalid enum values are rejected before any work happens and are not charged. Sending window '1y' returned INVALID_PARAM in 1.2 ms with detail.allowed listing ['30d','90d','180d','365d','all']. The same discipline applies to currency (19 values from USD to THB) and market. Failed calls cost nothing.

Everything else on the product is what you would expect and is populated: sku/style_id (FV5029-006), colorway, release_date, retail_price, brand, model, plus a market block with number_of_asks, number_of_bids, sales_last_72h, avg_price_90d, avg_price_annual, price_premium, volatility as a coefficient of variation, and ask_service_levels broken into standard, express_standard, express_expedited and express_next_day with their own counts, lowest asks and expected delivery dates. Product detail answered in about 750 ms in our runs.