Yahoo! Auctions Japan Listings Scraper — Bulk Data

What it does: Exports Yahoo! Auctions Japan live or ended auctions as rows. Use this listings scraper for inventory research and recurring price/bid observations.

You enter: Keywords, e.g. Nikon Z6 ボディ; live/closed/both; rows per keyword (100, up to 2,000); JPY band.

You get: Auction ID, title, displayed JPY price, buy-now price, price-floor flag, bids, end time, source status and URL. Seller ID/profile URL are included; other seller attributes depend on the search book.

Price: $0.0015 per delivered auction, with no keyword fee. Duplicate cards within the same keyword/book are dropped; overlapping keywords or books may return and charge the same ID again. No delivered auctions = no charge.

Example: Use keywords: ["Nikon Z6 ボディ"], status: "live" and maxListings: 100 for an inventory snapshot. Up to 100 delivered rows cost $0.15 in listing events. A live bid price may increase; inspect buyNowPriceJpy and priceIsFloor.

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 Yahoo! Auctions Japan Sold Price Summary & 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. Reaching the charge limit also leaves a free notice, even when some auctions were delivered. Notices are never charged — you pay per auction delivered.

{
  "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.

If the run's charge limit stops delivery, the notice has truncatedBy="charge-limit" and pushed is the number of auctions delivered for that keyword. Later keywords are not fetched after the budget is exhausted; their notices have unknown (null) source totals and pushed=0, rather than claiming no matches. The SDK writes only the rows the remaining event budget can cover. Unavailable or inconsistent charge receipts fail visibly instead of reporting fully paid delivery.

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's Maximum cost per run and account allowance can reduce the number of chargeable rows, and the default time limit is 300 seconds. One 2,000-row keyword costs $3.00 in listing events. Choose a sufficient run budget or split the terms across runs; a charge-limited result is partial and is marked by a free notice.

Use with AI agents

Connect to the Apify MCP server and identify this tool as jpmarketdata/yahoo-auction-listings. A prompt can set the book, price band and maximum delivered-row cost explicitly:

Use jpmarketdata/yahoo-auction-listings to export Yahoo Auctions Japan live listings for Nikon Z6 camera bodies. Run with keywords: ["Nikon Z6 ボディ"], status: "live", maxListings: 100, priceMinJpy: 50000 and priceMaxJpy: 150000. Return auction IDs, titles, displayed JPY prices, buy-now prices, price-floor flags, bids, end times and URLs. Keep type: "listing" rows separate from search_summary notices. Explain that current bids may rise and this is a bounded snapshot. Flag partial results or charge-limit notices. Do not repeat the run unless I ask.

At $0.0015 per delivered auction, this example costs at most $0.15 in listing events, before trial credits and any applicable Apify platform charges. Use status: "closed" for ended rows, including possible unsold auctions.

FAQ

How do I scrape live and ended Yahoo Auctions Japan listings?

Use status: "live", "closed" or "both" with your keywords and maxListings limit. Up to 2,000 rows per keyword are available; both shares that budget across the two search books. Export JSON or CSV in Apify Console, or read the run's dataset through Apify API.

Are ended Yahoo auctions the same as sold auctions?

No. Raw ended results can include auctions with no bids, and an ended result does not independently verify payment. Inspect bidCount and source status. For a calculated benchmark from priced ended auctions with bids, use Yahoo! Auctions Japan Sold Price Summary & History.

Can I buy an item at its displayed live auction price?

A live priceJpy is the current bid or displayed price and can rise. Read buyNowPriceJpy for a published buy-now amount and priceIsFloor for a live auction without a buy-now price. A false floor flag does not guarantee that the current bid is the buy-now amount; check the source listing before buying.

Can I monitor auction prices and bids over time?

Save the same keywords, status, price band and row budget as an Apify Task, then collect recurring snapshots. Store auction id and run timestamps; endTime is an auction end time, not collection time. A missing ID is not proof of a sale or deletion, and repeated runs charge the delivered rows again. Check logs and free search_summary notices for partial coverage or charge limits.

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).
• Source failures are reported. Read run logs and partial-result warnings; a successful run can contain fewer completed searches than requested. An acquisition failure is not proof of zero market matches.
• 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. Only seller IDs and public profile attributes exposed by search are included; no extra seller-profile requests.

More tools by the same author

• Yahoo! Auctions Japan Sold Price Summary & History
• Yahoo! Auctions Japan Monthly History — Legacy Task/API
• Yahoo! Auctions Japan Deals — Below Past Sold Prices
• Mercari Japan Price Summary — Sold Out & Live
• 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.