Yahoo! Auctions Japan Keyword Watch

Give it one or more keywords and it returns the listings Yahoo! Auctions Japan would show you for each: current price, buy-it-now price, bid count, end time, seller id, thumbnail, free-shipping flag and a condition badge where one is printed. Built for the two jobs a keyword watch is actually for: catching new listings the moment they post, and tracking a price band over time.

What one row contains

Field	Notes
keyword	Which of your search keywords this row matched.
auction_id	Yahoo's own listing id, e.g. j1245760382.
url	auctions.yahoo.co.jp/jp/auction/<auction_id>.
title	The listing title, as the seller wrote it.
current_price_jpy	Integer yen - the current bid, or the fixed price on a no-bid listing.
buy_now_price_jpy	Integer yen, null when the listing has no 即決 (buy-it-now) option.
bid_count	Number of bids so far. Yahoo prints 0 here for a fixed-price/shop-style listing too, so 0 is a real answer, not an absence.
end_time_iso	Computed from the listing's own end-time attribute; parseable whenever Yahoo sends that attribute.
end_time_raw	What Yahoo actually prints next to the countdown icon - a relative string such as "17時間" or "3日", not an absolute date. Kept verbatim because it is what a shopper reads.
seller_id	Yahoo's opaque per-listing seller id. The search page names no seller by handle, so this is the closest thing to one.
thumbnail_url	The listing's thumbnail image.
free_shipping	true only when Yahoo's own free-shipping flag is set on the card; false otherwise. Always one or the other - Yahoo prints this on every card.
condition	Read off a condition badge (e.g. "未使用") when the card carries one. Null on most rows: unlike Mercari, Yahoo! Auctions' search grid does not print a condition grade for every listing, only an occasional icon.

Why so many nullable fields

The search grid is one template rendering both auctions and fixed-price, shop-style listings. A listing with no buy-it-now option has nothing there to print, and most listings carry no condition badge at all. A 0 or an empty string in either place would read as a measurement - "free", "new" - when the truth is that Yahoo did not say. Null is the honest answer, field by field, as above.

Sort order, for a keyword or price watch

Set Sort order to Newest first (Yahoo's own 新着順) to see the listings that appeared since you last ran this actor, without re-reading the whole result set. Ending soonest and the price sorts are Yahoo's own too - every value was read off the site's live sort dropdown, not guessed:

Sort order	Yahoo's own label
newest	新着順
ending_soon / ending_latest	残り時間の短い順 / 残り時間の長い順
price_asc / price_desc	現在価格の安い順 / 高い順
buy_now_price_asc / buy_now_price_desc	即決価格の安い順 / 高い順
bids_desc / bids_asc	入札件数の多い順 / 少ない順

priceMin / priceMax filter on current price, in yen, the same way the site's own price band filter does.

Multiple keywords, one run

keywords takes a list. Each keyword is searched and paged through in turn; a listing that matches more than one of your keywords is written and billed once, not once per keyword it matched. maxItems is a budget for the whole run, shared across every keyword, not a per-keyword limit.

How it fetches

Yahoo! Auctions Japan's search results page (/search/search?p=<keyword>) is the same endpoint the site's own search box calls, so that is what this actor fetches - there is no separate JSON API worth calling instead. Pagination uses the site's own b (item offset) and n (page size, capped at 100) parameters, and 100 items per request is the fewest requests per row.

A zero-match search comes back as HTTP 404, not 200. Measured 2026-09-28 against a nonsense keyword: Yahoo serves its own real "no matches" page - full site template, an honest 0件 count - under a 404 status. That is a real answer, not a refusal, so this actor reads the page body rather than trusting the status code: a genuine empty result costs the run's start fee and nothing else, the same as an empty result on any other actor in this line.

No bot check or interstitial was seen while building this: a plain fetch with no proxy at all got HTTP 200 with full results, every time, from this VM on 2026-09-28. Anything that is neither a real results grid nor Yahoo's own empty page is still treated as a refusal and retried from a different address - that branch exists for the day the site's defenses change, not because it was observed.

Proxy

Datacenter is the default, and the cheapest route that works. Measured 2026-09-28: this actor's own datacenter exit, an Apify residential exit, and a Japan-pinned residential exit all got full results with no challenge. Pay for residential only if you start seeing refusals from datacenter - nothing here promises that stays true forever, only that it was true on the day this shipped.

Billing

Pay per event, all-in: $0.00042 per listing row, plus $0.002 actor-start per run, charged once your input has parsed (so a run that fails on bad input costs nothing). Platform usage - compute, proxy, dataset writes - is included in that price; you are not billed for it on top, and this actor is not set up to pass its own platform costs on to you the way some listings do.

By comparison, sigma-dev's Yahoo Auctions actor lists $0.0006 per item plus a $0.05 actor-start fee - and turns on isPPEPlatformUsagePaidByUser, which means its platform usage costs are billed to you on top of both of those figures. This actor's $0.00042 per-listing price is already 30% under that actor's headline per-item price, before counting what the usage passthrough adds to it.