Yahoo! Auctions Japan Bulk Listings — Live or Ended

What it does: Exports Yahoo! Auctions Japan live or ended auctions as rows with IDs, prices, bids and end times for your own recurring analysis.

You enter: search terms, one or many, e.g. Nikon Z6; status live/ended/both; rows per term (100); price band

You get: one row per auction: title, current price (yen), buy-now price, whether that price is only a floor, bid count, end time (UTC), status, URL, seller ID, rating and shop flag. Up to 2,000 rows per term, split (not doubled) across both books.

Price: $0.0015 per auction delivered, and nothing else — no per-keyword charge, same rate on every plan. Nothing found = no charge.

Example: enter Nikon Z6 → one row per auction, live and ended. On a measured sample, 10 of 50 live auctions had no buy-now price, so their current price is only a floor

Unofficial — not affiliated with Yahoo! Auctions. Reads public pages only.

Choose the product for your job

Use this Actor for listing rows: one row per auction, up to 2,000 per keyword, selecting live, closed or both and optional JPY price bounds. $0.0015 per delivered auction, with no per-keyword fee. Ended auctions can include no-sale results; their source status and bids remain visible.

For calculated sold-price medians and optional monthly history, use Sold Price Summary & Monthly History. Its fee is $0.02 per keyword plus $0.002 per optional auction row; individual rows are ON by default, so switch them off for summaries only. For exact known URLs, use Item Details by URL.

What it costs

$0.0015 per auction returned, and nothing else. There is no charge for the search itself and no monthly fee, and the rate is the same on every plan. So 20 auctions cost $0.030, 60 cost $0.090, and 500 cost $0.750. Auctions you do not receive are not charged, so a search that finds nothing is free.

The one thing you must know about auction prices

A live auction's current price is a floor, not a price. It only ever rises with bids. An open auction sitting at ¥80,000 is not something you can buy for ¥80,000 — it is an auction that has not finished.

So every record carries both prices and a flag:

• priceJpy — the displayed current or closing price. A closed result alone does not prove payment or a completed transaction; a live auction can receive further bids.
• buyNowPriceJpy — the price you can actually pay today, or null when the auction has none.
• priceIsFloor — true exactly when a live auction has no buy-now price, i.e. when priceJpy cannot be paid.

Yahoo's own page writes buynowprice="0" for an auction with no buy-now price. That is absence, not a price of ¥0, so it comes back as null — on a measured sample, 10 of 50 live auctions.

Output

One record per auction, the same shape for live and ended auctions, so nothing has to look at status to read a price. Measured on 2026-08-10 (real run):

{
  "type": "listing",
  "keyword": "Nikon Z6",
  "status": "closed",
  "id": "v1240192942",
  "title": "【全額返金保証】【最速発送】Nikon デジタル一眼 Z6 ボディ 美品 動作確認済",
  "priceJpy": 88935,
  "buyNowPriceJpy": 88935,
  "priceIsFloor": false,
  "bidCount": 1,
  "endTime": "2026-08-10T03:17:41+00:00",
  "sellerId": "2DrgwuqoWA22gGxT3REVyLYu6F3rS",
  "sellerName": "********",
  "sellerRating": "98.6%",
  "sellerIsStore": true,
  "sellerUrl": "https://auctions.yahoo.co.jp/seller/2DrgwuqoWA22gGxT3REVyLYu6F3rS",
  "url": "https://auctions.yahoo.co.jp/jp/auction/v1240192942"
}

End times are always UTC ISO-8601, from both books.

When a search term returns nothing

A search term that delivers no auction leaves one free search_summary row instead, so a run over several terms shows you which one was empty rather than nothing at all. It is never charged — you pay per auction delivered, and this is not an auction.

{
  "type": "search_summary",
  "keyword": "zzzqqxnotarealproduct",
  "totalFound": 0,
  "liveFound": 0,
  "closedFound": 0,
  "pushed": 0,
  "duplicatesDropped": 0,
  "keywordStatus": "not_found",
  "hint": "No auction matches this search and price range. Try a wider price range, another way of writing the model number (α7 IV / ILCE-7M4), or a broader keyword.",
  "checkedAt": "2026-08-18T00:00:00+00:00"
}

Example values (shape only — the keyword and its 0 are measured 2026-08-18, the timestamp is illustrative)

keywordStatus is not_found when the requested search and price range have no matches. For a locally filtered closed search, that requires complete, readable source exhaustion. unknown means the result is unconfirmed — for example, one requested book failed and the other came back empty. Unconfirmed counts are null; a failure is never reported as not_found.

Input

Field	What it does
keywords	One or more search terms (required).
status	live, closed, or both (default).
maxListings	Auctions per search term, 10–2000. With both, this is the total and is split between the two books — it is not doubled.
priceMinJpy / priceMaxJpy	Inclusive displayed-price band. Live searches send it to Yahoo; closed searches apply it locally while paging the unfiltered search.

Closed price bands can require many more source pages than delivered rows. The Actor keeps paging until it has the requested number of matching unique auctions or has read the available search to the end. The unfiltered Yahoo total is never presented as the total within your band; that filtered count stays unknown until a complete readable traversal establishes it. An unreadable page, incomplete traversal, or unknown price cannot establish zero matches. Requests remain throttled, and the existing 300-second run timeout still applies. A narrow band over a broad keyword can therefore time out; use a more specific keyword or allow more run time when appropriate.

Repeat a search without duplicating your database

A repeat run is a fresh search, with the same per-delivered-row charge even when you received an auction before. This is useful for price/bid observations and inventory watchlists; it is not an incremental feed.

• Use id as the auction key in your database; a relisted auction with a new ID is a separate record. Save each observation with its run ID. Within a run, this Actor drops repeated cards for the same keyword and book. Overlapping keywords, or an auction appearing in both live and closed books, can still deliver and charge multiple rows for one ID. The example below collapses identical market observations and retains distinct price/status variants without guessing which row was fetched last.
• status: "live" uses the live search book; "closed" uses ended search results; "both" divides the per-term budget between them, with unused live capacity available to closed results. Each is a bounded slice in Yahoo's default search order. There is no chronological cursor or guarantee of the entire market, and malformed cards can reduce the delivered count.
• Compare only observations from the same search settings. A new ID means newly observed in your results, not necessarily newly listed. An absent ID can have moved beyond your page budget, outside a price band, out of the keyword match, or into an unavailable search book. Do not turn absence into "sold", deletion, or a zero price.
• endTime is Yahoo's auction end time, not the time this Actor observed the row. Listing rows have no checkedAt; store the run's startedAt and finishedAt as the collection interval. Only a free search_summary row has its own checkedAt.
• A run can succeed with one failed keyword or one failed book. Read the run log for errors and partial-result warnings; SUCCEEDED alone is not proof of complete coverage. Free search_summary rows describe searches, not auctions: filter type == "listing" for your item table and inspect notices separately.

Save the search and collect the next snapshot

1. Save a Task in Apify Console with your keywords, status, price band and maxListings. Use the same Task for each comparison; create a separate Task when the search scope changes. Set a run cost cap and a schedule that matches your business needs.
2. Run that Task again manually, from a schedule, or through the Task API. This request uses the saved input and starts one billable run; read its data.id as the run ID:

# Set APIFY_TOKEN in your environment and replace YOUR_TASK_ID.
curl --fail --silent --show-error --request POST \
  "https://api.apify.com/v2/actor-tasks/YOUR_TASK_ID/runs" \
  --header "Authorization: Bearer $APIFY_TOKEN" \
  --header 'Content-Type: application/json' --data '{}'

3. After it finishes, import the completed run. Save the Python example below as ingest_run.py; it uses only the standard library.

python3 ingest_run.py FIRST_RUN_ID snapshots.sqlite
python3 ingest_run.py NEXT_RUN_ID snapshots.sqlite

The example only reads an existing run and its dataset pages; it never starts a run. It accepts this Actor's SUCCEEDED runs, groups observations by listing id, and keeps both a run history (observations) and the most recently completed run that saw each ID (latest). Importing the same run twice adds no duplicate observations, and importing an older run cannot overwrite a newer one. A missing ID leaves the previous observation intact. The local database stores IDs, market prices/status/times and run metadata; it omits seller data and search text.

For example, query changes to IDs present in both runs (replace the two run IDs):

SELECT b.id, a.values_json AS previous, b.values_json AS current
FROM observations AS a JOIN observations AS b
  ON a.actor_id = b.actor_id AND a.id = b.id
WHERE a.run_id = 'FIRST_RUN_ID' AND b.run_id = 'NEXT_RUN_ID'
  AND a.values_json <> b.values_json;

Use a separate database for each saved Task/search scope. latest means last observed in a completed run, so check its run_id and finished_at before using an old price. This example is customer-side storage; the Actor itself keeps no state between runs.

What you get about the seller

Live rows return sellerId and sellerUrl; sellerName, sellerRating and sellerIsStore remain empty to preserve the established live-row contract. Closed results also return the display name (Yahoo may mask it as ********), rating and shop flag published by their search book. Missing attributes stay empty and are never filled in from the other book. Feedback text, review counts and scores are never returned, and a check in code asserts that on every record before it is sent.

Why you can trust the count

The current live page supplies its normal results, exact filtered total and page size in embedded JSON. Featured and recommended modules are excluded. The Actor follows that page size without setting a custom n parameter. The older HTML layout is also supported: cards are split on their opening tag, and counts come from the exact "すべて" tab rather than the approximate description.

Repeated auction IDs within each keyword/book are dropped, and malformed records are counted in the log. A missing or unreadable search payload, a loading/authentication response, or a positive count with no readable auctions is an error. Only a readable, explicit zero can mean no matches. If every requested search fails, the run fails; if another book succeeds, the log identifies the partial result.

Pricing

$0.0015 per auction delivered. Nothing is charged for the search itself, there is no monthly fee, and all plans pay the same rate. Auctions you do not receive are not charged.

Public pages only, no login, requests spaced out, no browser. Nothing is stored between runs.

A whole list in one run

keywords takes a list of terms; each returns up to 2,000 rows at $0.0015, and only delivered rows are charged.

Two limits for big pulls: the platform stops a run when it reaches its Maximum cost per run setting (default $3.00 = 2,000 rows), and the run's default time limit is 300 seconds. Both can be raised in the run options — or split the terms across runs.

If something goes wrong

• Wrong number or a failed run? Open a ticket on the Issues tab. I read every one and reply within 2 business days (Japan time).
• You never get a fake "empty" result. If the site can't be read, the run fails and says so.
• No results = no charge. You only pay for results you actually get.
• Checked every week. An automatic test runs this tool weekly; if the site changes, I fix it.
• Public pages only. No login, no personal data, and it goes easy on the site.

More tools by the same author

• Yahoo! Auctions Japan Sold Price Summary & Monthly History
• Yahoo! Auctions Japan Monthly History — Legacy Task/API
• Yahoo! Auctions Japan Deals — Below Past Sold Prices
• Mercari Japan Price Summary — Live or Sold Out
• Daikokuya Japan Buyback — What a Shop Actually Paid
• Hifido Japan Used Audio — What It Actually Sold For
• Japan Used Camera & Lens — Dealer Price vs Sold Price
• Used iPhone & Android Prices Japan — Dealer vs Sold

All tools (Japan marketplaces, real estate, jobs, racing, prediction markets): https://apify.com/jpmarketdata

Disclaimer

Unofficial, independent tool — not affiliated with, endorsed by, or sponsored by Yahoo! Auctions. Product names and logos belong to their owners and only say where the data comes from. Data is read from public pages, for market research; check before you act on it.