Sneaker resale price API: ReefAPI vs Retailed

$0.67–$1.50 / 1,000 credits on monthly billing, or $0.33–$0.75 / 1,000 credits paid yearly (−50%). Credits roll over and never expire, and every engine draws from the same balance. Failed calls are free except verified SHEIN NOT_FOUND on product/detail and price (4 credits). Credits are not requests: measured across 1,124 catalog actions on 2026-08-25, 67% cost one credit, 18% cost two and 5% cost three.

Not published. We read retailed.io/pricing, retailed.io/datasources and the documentation introduction on 2026-09-24 and none of them says whether a failed or blocked request consumes a credit, so we are not putting an answer in their mouth. On our side a failed or blocked call is not charged, except verified SHEIN NOT_FOUND on product/detail and price (4 credits), which does not touch any engine on this page.

A product's lowest ask and highest bid are not a spread, and reading them as one prices the wrong size

This is the field that goes wrong most often in resale pricing, so it is worth being exact. market.lowest_ask is the cheapest ask ACROSS ALL SIZES and market.highest_bid is the dearest bid across all sizes, so a product can correctly report a highest_bid of $286 against a lowest_ask of $154 — those are two different shoes in two different sizes and the difference is not arbitrage. Only variants[] gives a real per-size spread, and there the ask sits above the bid as it should: size 3.5 asked $188 against a bid of $115 on the same run. If your comp engine subtracts the product-level bid from the product-level ask, it is computing a number that does not exist.

retail_price does not convert, so a premium computed against it in euros is wrong

Against us. Reading the same product on the German market in EUR changed every market number — the lowest ask went from $154 to 103, and the per-size asks changed entirely, because it is a different order book rather than a converted one. retail_price stayed at 180 through the change. So retail_price is a USD figure whatever currency you asked for, and a price premium of (last_sale − retail) / retail is only meaningful in USD. The variant count stayed at the same 26 sizes on both markets, so the size grid is global and the prices are not.

price_history samples the last 400 sales, not the window you asked for

Against us, and it costs 3 credits, the dearest action on the engine, so check before you pay for a long one. Asking a 365-day window bucketed by month returned ONE point, with summary.sales_sampled at 400 and window_complete false — on a shoe selling that fast, 400 sales is a few weeks, not a year. A 90-day window bucketed by week returned five points from the same product. The endpoint does tell you it is incomplete, which is the behaviour you want, but a trend line built without reading window_complete will be a trend line over an unknown and variable period.

The manufacturer style code is filled on sneakers and almost nowhere else

Against us, though it is the source's doing. sku was filled on 20 of 20 sneaker rows, 2 of 14 watch rows and 0 of 20 trading-card rows. Streetwear and collectibles have no manufacturer style code to carry. If the key you join on across venues is the style code — the natural choice, because DZ5485-612 means the same shoe on StockX, GOAT and a retailer — this engine will join sneakers to your catalogue and very little else. Outside sneakers you are matching on title and colourway, which is a different and worse problem.

A zero-ask product is not a cheap product, it is an unbuyable one

Measured over three queries of 40 cards each. Eighteen cards came back with zero asks and every one of the eighteen had lowest_ask null; 102 cards had asks and every one of those was priced. So in_stock is derived from the source's own market.state.numberOfAsks rather than from a price being present, and a product with bids but no asks is false, because nobody can buy it. A comp set that silently drops the null-priced rows loses exactly the items whose market has gone. In the same session the cheaper price action returned the same market numbers from 6,105 upstream bytes against product_detail's 10,976, at 0.99 s against 1.06 s.

Forty of forty sold rows carried the asking price and the real one together

This is the single reason Grailed is on this page. Every sold row we measured carried sold_price, sold_at and the original asking price side by side. Eleven of the forty sold at exactly the asking price; the rest closed below it, in a band running from a few per cent under to roughly half off. You do not have to infer the discount from two separate calls, and you do not have to treat an asking price as a comp. The forty newest sold rows for one query spanned three days, so sorted newest-first this is a rolling window of what actually cleared rather than an archive dump — which is what makes it usable for pricing an item today.

Paging stops at exactly one thousand rows, and the reported total is much larger

Against us, and it decides how you build the crawl. Page 25 returned a full forty rows. Page 26 returned zero, with has_more false and the reported total dropping to zero — a clean stop, but a stop, and it lands at 25 pages of 40 against the 22,929 results the same query claimed. Narrow with designer, size, category and a price band instead of walking a broad query to the end, because there is no end to reach. Run twice, the same comp query returned the identical forty listing ids both times, and page one and page two shared nothing, so a nightly diff over a narrowed query is signal rather than noise.

The per-size grid is the comp, and the sizes without a live ask are simply absent

On the Air Jordan 1 'Chicago' the used grid returned real per-size asks: size 8 at $378 across 10 listings, size 9 at $425 across 19, size 9.5 at $503 across 17, size 10.5 at $451 across 15, size 11 at $347 across 13, with the overall lowest at size 8.5 for $268 — a spread of $235 between the cheapest and dearest size of one shoe, which is why a single headline price is not a comp. The call took 4.2 s because it fans out one request per size under a bounded concurrency cap. The same run returned the catalogue record for the shoe with a GOAT display price of $160, so the resale premium on the cheapest size was already over 60%.

The local display price is not pinned by the country parameter

Against us, twice over. First, the same product answered USD 160.00 and then EUR 139.00 minutes apart while the country parameter did not change, so the display_price_local block is display-only and must not be computed on — do the arithmetic on the *_usd fields, which are decimal dollars rather than cents, where 257.0 means $257 and dividing by 100 puts you out by two orders of magnitude. Second, only sizes with a live ask come back: 15 of the 23 sizes we probed returned a row and the other 8 were absent rather than null, so join product_detail.size_range if you need the gaps marked as gaps. The condition parameter has exactly two values, used and new_no_defects; used is the deep resale pool and new_no_defects is often honestly empty in smaller markets.

No sales history exists upstream, and we probed it properly before saying so

Against us, and it is the first thing a price tracker needs to know. Sold-listings, price-history, offers and rankings routes all answer 404 — and those 404s mean the route does not exist rather than that we were blocked, because every route verdict was taken by first confirming that a known-good endpoint answered 200 under exactly the same conditions, and only then probing the unknown one. Without that control call, ten non-existent routes read as "exists but walled". What the source does publish is live listings and the current floor per grade, so a trend line has to come from your own snapshots over time. Over 77 live calls the engine returned 76 ok, 98.7%, with search at a 3.0 s median and the 30-product batch at 1.6 s.

Listing counts are strings capped at "99+", and the cap hits exactly the busiest cards

Against us, caught in review before the engine shipped. The source returns counts as strings and caps them at "99+", so int() failed and the field vanished for precisely the cards with the deepest markets — 5 of 5 rows on a popular search. It is now parsed to 99 with count_is_lower_bound true beside it. The proof is one card reading 99 on a search row, capped, and 599 on its own detail record. Two other traps from the same review: the price and the listing count are siblings of the product object rather than inside it, so parsing the product alone silently dropped both, and epoch zero is the source's way of saying "unknown date", returned as null rather than as 1 January 1970.