Yahoo! Auctions Japan Sold Prices & Seller Intel

Current listings tell you what an item is for sale for. Sold listings tell you what it is worth — and that is the buying decision.

This Actor scrapes Yahoo! Auctions Japan (ヤフオク!) sold/closed history — up to 180 days of it — and returns not just the raw sales but computed price comps and per-seller intelligence. No Yahoo account or login needed.

Built for resellers sourcing from Japan, proxy-buying services, arbitrage buyers, and anyone who needs to know what Japanese buyers actually paid.

What makes this different

Most Yahoo Auctions scrapers hand you a list of listings. This one also tells you what the listings mean:

• Real demand signals, not just prices. Every sale comes with its bid count, distinct bidder count, watcher count, page views and impressions. Two items that both sold for ¥30,000 are not equal if one drew 40 bidders and the other drew one.
• Price trend, not just a median. Every query gets a priceTrend30v90 figure comparing the last 30 days' median against days 31–90. You learn whether a price is holding, climbing or sliding.
• Seller intelligence. Per-seller GMV, median price, sales velocity, category mix and a relist-rate proxy — who the real players are in your niche, and what they clear.
• Gets past Yahoo's 10,000-result ceiling. Yahoo silently truncates any query at ~10,000 rows. This Actor detects that and automatically splits the query into price bands so you get the whole result set.
• Built to survive Yahoo's redeploys. Yahoo's result rows use hashed CSS class names that change on every front-end deploy, which is why selector-based scrapers break so often. This Actor reads each row's structured data-cl-params payload instead, with a text fallback if that ever disappears.

What you get

Sold items (default dataset)

Field	Description
auctionId, url, title, imageUrl	Listing identity
finalPrice, startPrice, currency	What it sold for, and what it opened at
priceVsStartMultiple	Final ÷ start — how hard bidding drove it
bidCount, bidderCount	Total bids, and how many distinct people competed
watchCount, pageViews, impressions	Demand before the sale
viewsPerBid	Views needed per bid — attention-to-action efficiency
startedAt, endedAt, lastBidAt, durationHours	Full timing, ISO 8601 UTC
conditionLabel	Yahoo's condition grade (未使用, 目立った傷や汚れなし, …)
categoryId, categoryPath	Category and breadcrumb trail
sellerId, sellerUrl, sellerRating	Who sold it, and their rating %
shipsFromPrefecture, freeShipping	Dispatch region and shipping terms
isAppraised, catalogId	Yahoo appraisal badge; product-catalog grouping id
marketplace	auction or fleamarket

Price comps (COMPS in the key-value store)

soldCount, minPrice, maxPrice, avgPrice, medianPrice, trimmedMeanPrice, p25Price, p75Price, p25ToP75Spread, stdDevPrice, totalGmv, avgBidCount, avgBidderCount, pctSingleBid, avgWatchCount, avgPageViews, soldPerWeek, topSellers, topCategories, historyCoverageDays, sold30d, sold31to90d, priceTrend30v90, priceTrendPct, priceTrendStrata.

Three fields worth calling out:

• trimmedMeanPrice discards the top and bottom 10% before averaging. Sold-price data is polluted by ¥1 junk lots and outlier whale sales, so this is usually a better "what is it worth" number than the raw average. On a real ロレックス sample the raw average was ¥183,175 while the trimmed mean was ¥46,798 — the average was being dragged by a single ¥3.5M sale.

• pctSingleBid is the share of sales that closed with one bid. A high value means buyers are not competing, so the price is closer to a ceiling than a floor.

• priceTrend30v90 needs history depth to exist, and this is worth understanding before you rely on it. Yahoo returns results newest-first and offers no date filter, so a popular keyword's first few hundred rows may all come from the last day or two. historyCoverageDays tells you how far back your sample actually reached; if the trend is null, priceTrendNote explains exactly why and what to change. To get a usable trend, narrow the query (a specific model rather than a brand, a category, or a price range) or raise maxItems so the crawl reaches past 30 days.

  The trend is computed stratified by sub-query, not on the pooled sample. When a query is split into price bands, those bands reach different depths in time, so comparing pooled windows would compare different price mixes rather than price movement. Ratios are computed within each band and the median taken; priceTrendStrata reports how many bands qualified. For the same reason, median30d and median31to90d are only populated for queries that were not split.

Yahoo's own reported lowest/average/highest (yahooMinPrice, yahooAvgPrice, yahooMaxPrice) and total (yahooReportedTotal) are included so you can cross-check our figures against the source.

Seller intelligence (SELLERS in the key-value store)

displayName, ratingPercent, ratingCount, isVerified, activeListingCount, soldCount180d, gmv180d, medianSoldPrice, avgBidCount, soldPerWeek, soldToActiveRatio, relistRateProxy, uniqueTitles, categoryMix, firstSeenSoldAt, lastSoldAt.

How to use it

Give it at least one of: search terms, category IDs, seller IDs, or start URLs.

Japanese keywords return far more than English ones, because that is how items are listed. ロレックス returns roughly 18,000 sales; "Rolex" returns a fraction of that.

Example: what did this watch actually sell for?

{
  "searchTerms": ["ロレックス エクスプローラー"],
  "excludeKeywords": "ジャンク レプリカ 修理",
  "minPrice": 100000,
  "soldWithinDays": 90,
  "maxItems": 500
}

Example: profile a competitor

{
  "sellerIds": ["JH3J1n3GZZA4rXChorKRKxMekEgw"],
  "marketplace": "both",
  "includeSellerIntel": true
}

Returns that seller's entire 180-day sold history plus a computed intel record.

Aggregates are written to the run's key-value store under COMPS and SELLERS, and linked from the Output tab. Set writeNamedDatasets to also mirror them into persistent comps and sellers datasets; that is off by default because named datasets accumulate across runs and are not available on every plan.

Example: sweep a category daily for new sales

{
  "categoryIds": ["23336"],
  "soldWithinDays": 2,
  "incrementalMode": true,
  "autoSlicePriceBands": true
}

With incrementalMode, previously seen sales are remembered and skipped, so a scheduled run returns only what is new. State lives in a named key-value store (stateStoreName, default yahoo-auctions-sold-state) because a run's own default store is created fresh each time and cannot carry state forward. Give each scheduled watch list its own stateStoreName so their histories stay separate.

Limitations — read these before you buy

These are properties of Yahoo's data, not bugs, and we would rather you know up front.

• 180 days maximum. Yahoo does not retain sold history beyond that. soldWithinDays cannot exceed 180.
• Sold data contains only items that sold. Listings that ended without a sale are not published by Yahoo anywhere. A true sell-through rate is therefore not computable from this source, and we do not pretend otherwise. What you get instead: soldToActiveRatio (180-day sales against current active listings) as a velocity proxy, and relistRateProxy (repeated identical titles from one seller) as an indirect unsold signal.
• No custom sort order. Yahoo's robots.txt disallows the select= parameter, so results come back newest-first only. In practice this is the useful order anyway, and it is what makes date-bounded and incremental crawling efficient.
• No seller feedback history or bidder identities. Yahoo's robots.txt disallows /jp/show/rating and /jp/show/bid_hist, so this Actor does not touch them. You get the seller's aggregate rating %, not their individual reviews; and bidder counts, not bidder names.
• ~10,000 rows per query, worked around by automatic price-band splitting. With autoSlicePriceBands off, broad queries truncate.
• Flea Market rows are mixed in. Yahoo returns Auctions and Flea Market (フリマ) sales together, and the auction share depends heavily on the keyword — around 44 of 50 rows for ロレックス, but only about 2 of 50 for ポケモンカード. Flea-market sales are fixed-price, so they carry no bid, bidder or watcher data. Default is auctions only; set marketplace to both to keep everything.
• Trend figures need history depth, and often will not be available on broad keywords. Because Yahoo serves newest-first with no date filter, reaching days 31–90 means paginating that far back. priceTrend30v90 is null unless a single sub-query holds at least 5 sales in both windows; historyCoverageDays and priceTrendNote always tell you where you stand. Narrow queries get trends; "every Rolex ever" does not.

Compliance

This Actor only requests paths Yahoo's robots.txt permits. /closedsearch/closedsearch is explicitly allowed there (an Allow: rule that overrides the broader Disallow: /closedsearch/), as is the bare /seller/<id> profile path.

Parameters Yahoo disallows — n, select, aucminprice, aucmaxprice, istatus, thumb, pstagefree, offer, abatch, jpypayment, wheel_spec_id — are refused in code, in the one module that builds every request URL. If you paste a browser URL containing one into startUrls, it is stripped and the URL rebuilt before the request goes out.

No login is used and no personal data is collected: seller IDs are Yahoo's own opaque pseudonymous identifiers, and locations are coarse prefecture-level dispatch regions.

Separately, Yahoo! JAPAN's Terms of Service place restrictions on automated access. Complying with those, and with the laws that apply to you, is your responsibility as the operator of this Actor.

Proxies and blocking

Yahoo tolerates datacenter IP ranges inconsistently. The Actor starts on Apify Proxy's automatic mode (datacenter IPs, available on every plan) and escalates to Japanese residential only if the first tier returns no data and shows block signals — so you pay for residential traffic only when it is actually needed. Tiers whose proxy groups your plan does not include are skipped automatically rather than failing the run.

If your plan includes proxy country selection, setting the country to Japan in the proxy input improves results: a Japanese exit IP keeps prices and shipping in their domestic form.

Set escalateToResidentialOnBlock to false to cap costs strictly.

Pricing

Pay per result:

Event	Price
Sold item	$0.003
Seller profile	$0.010
Price comps report	$0.050

Output example

{
  "auctionId": "p1246400393",
  "title": "未開封 ポケカ30周年BOXシュリンクあり30th CELEBRATION 拡張パック BOX",
  "marketplace": "auction",
  "finalPrice": 25500,
  "startPrice": 1,
  "currency": "JPY",
  "priceVsStartMultiple": 25500.0,
  "bidCount": 17,
  "bidderCount": 12,
  "watchCount": 14,
  "pageViews": 142,
  "impressions": 3038,
  "viewsPerBid": 8.35,
  "startedAt": "2026-09-29T23:03:36Z",
  "endedAt": "2026-10-02T01:03:35Z",
  "durationHours": 50.0,
  "conditionLabel": "未使用",
  "categoryPath": ["トレーディングカードゲーム", "ポケモンカードゲーム", "パック、ボックス、特殊セット"],
  "sellerId": "72SwpB56r5WsLEsThadruLfbxe3Sn",
  "sellerRating": 100.0,
  "shipsFromPrefecture": "東京都",
  "freeShipping": false,
  "isAppraised": true,
  "catalogId": "e67ddf3616"
}

Running it locally

$apify run

Put your input in storage/key_value_stores/default/INPUT.json. Results land in storage/datasets/default/.

Support

Found a field that stopped populating, or a keyword that returns nothing? Yahoo changes its front end regularly. Open an issue on the Actor's page with the input you used and it will be looked at.