Mercari Japan Sold Listings Scraper

This Actor is for Mercari Japan (jp.mercari.com) — not Mercari US. If you're looking for the US Mercari marketplace, this is the wrong Actor. This one searches Japan's largest C2C marketplace and returns sold listings with their final sale price, so you can see what things actually sold for, not just what sellers are asking.

Give it one or more keywords, get back:

• A record per sold item — title, price in JPY, condition, seller, images, link.
• Per-keyword price statistics — median, average, min, max, 25th/75th percentile.

Who this is for

• Reseller sourcing — before you list Japanese goods on eBay/Etsy/Poshmark, check what comparable items actually sold for on Mercari Japan to price competitively and gauge demand.
• Proxy-buying / daikou pricing — if you run a proxy-buying service (in the ZenMarket/Buyee space) sourcing from Mercari on behalf of overseas customers, use sold-price data to quote realistic item costs before you commit to a purchase.
• Market research — track how prices for a category (trading cards, streetwear, retro electronics, anime merch, etc.) move over time by running the same keywords periodically and comparing the aggregate stats.

Input

Field	Type	Default	Notes
keywords	string[]	— (required)	Search terms. Japanese keywords return more precise results than romanized/English ones — Mercari Japan's search is tuned for Japanese input. E.g. use ポケモンカード rather than pokemon card.
soldOnly	boolean	true	Keep only sold listings. See "How sold-only filtering works" below.
priceMin / priceMax	number	—	JPY price bounds.
itemCondition	string[]	—	Any of new, like_new, no_signs_of_wear, some_signs_of_wear, signs_of_wear, poor. Leave empty for all conditions.
categoryId	string	—	Mercari's numeric category_id (as seen in jp.mercari.com search URLs).
maxItemsPerKeyword	integer	100	Upper bound per keyword (max 100).
includeAggregates	boolean	true	Emit per-keyword price statistics (see Output).

Example input:

{
  "keywords": ["ポケモンカード", "iPhone 13"],
  "soldOnly": true,
  "priceMin": 1000,
  "priceMax": 50000,
  "maxItemsPerKeyword": 50,
  "includeAggregates": true
}

Output

Item records (default dataset)

One record per sold item found:

{
  "id": "m36432422259",
  "title": "【未使用美品】ピカチュウ ジムプロモ wcs 10枚セット",
  "priceJpy": 9999,
  "currency": "JPY",
  "status": "sold_out",
  "condition": "新品、未使用",
  "brand": null,
  "imageUrl": "https://static.mercdn.net/item/detail/orig/photos/m36432422259_1.jpg",
  "itemUrl": "https://jp.mercari.com/item/m36432422259",
  "sellerId": "515310776",
  "keyword": "ポケモンカード",
  "scrapedAt": "2026-07-09T05:35:52.515Z"
}

condition and brand are Mercari's own Japanese-language labels (e.g. 新品、未使用 = "new, unused"), passed through as-is rather than translated, since translation can lose nuance sellers rely on. brand is null for listings where the seller didn't tag a brand (common outside fashion/goods categories). This Actor does not report a sold date — see the FAQ entry "Why doesn't this Actor report a sold date?" below.

Per-keyword aggregates (named dataset aggregates)

When includeAggregates is true, one extra record per keyword goes to a separate named dataset called aggregates (kept apart from item records so the two shapes never mix in one dataset). Access it via the Apify API/SDK as <run>/aggregates or through the Actor run's dataset list in the console.

{
  "keyword": "ポケモンカード",
  "count": 3,
  "medianPriceJpy": 4500,
  "avgPriceJpy": 5400,
  "minPriceJpy": 1700,
  "maxPriceJpy": 9999,
  "p25PriceJpy": 3100,
  "p75PriceJpy": 7250
}

How sold-only filtering works

Mercari's search accepts a status=sold_out URL parameter, but we verified live (2026-07-09) that it does not reliably restrict server-side results — a plain search page mixed sold and actively-listed items together. This Actor therefore always enforces "sold only" itself, by checking each result card's own "売り切れ" (sold) badge before deciding to visit it. This is more robust than trusting the query parameter, and means results are correctly sold-only regardless of whether Mercari's server-side behavior changes in the future. One side effect: sold items are a minority of any given result page, so collecting many sold items for a keyword may take several search-result pages even though maxItemsPerKeyword looks small.

Known limitations

• itemCondition filtering happens after fetching each item's detail page, not via a Mercari search-time filter, because the numeric IDs Mercari uses for its own condition filter weren't reverse-engineered for this version. This costs one extra page load per candidate item but is otherwise transparent to you.
• itemCondition matching relies on Mercari's own Japanese condition labels (e.g. 新品、未使用). Only the new label was confirmed against a live item during this version's development; the other five values are inferred from Mercari's published condition taxonomy and have not individually been re-verified against live pages yet (planned for a future version). If a run using itemCondition returns unexpectedly few or zero items, a label mismatch here — not an absence of matching listings — is the first thing to suspect; the Actor logs a warning when this happens.
• status for non-sold items is best-effort. When soldOnly is false, items without a "sold" badge are reported as on_sale, but Mercari also has an in-progress-transaction state ("取引中") this Actor does not currently distinguish from active listings.

What this Actor won't do

It only reads public pages (/search, /item/...) that jp.mercari.com's robots.txt allows. It never calls Mercari's internal API endpoints (jp.mercari.com/v1, /v2, or api.mercari.jp), and it never logs in. It also runs at a fixed, deliberately slow pace — one request at a time, at least 3.5 seconds apart — and this is hard-coded, not something you can turn up from the input even if you wanted faster results. Sold-price data is a delicate thing to make freely scrapable at scale; going slow is the price of staying invited.

FAQ

Is this Mercari US or Mercari Japan? Japan (jp.mercari.com) only. Mercari US has an entirely separate site and catalog; this Actor cannot search it.

Why does the same keyword return different items each run? Mercari's search ranks by relevance/recency, and new items sell continuously. Re-running periodically is the intended way to track price trends via the aggregate stats.

Why are there fewer results than maxItemsPerKeyword? maxItemsPerKeyword caps how many candidate items we queue up for a detail-page visit — not how many end up in your output. Fewer final results than that number can happen because: (1) fewer than that many sold items exist for the keyword within the pages we crawled, (2) itemCondition/ priceMin/priceMax filtered some out after the detail page was fetched, or (3) a request failed after retries — check the failed-requests named dataset for details on any skipped items. Using itemCondition alongside a low maxItemsPerKeyword makes this more likely, since every candidate that gets filtered out post-fetch reduces your final count without being replaced.

Why doesn't this Actor report a sold date? Because Mercari's public search and item pages genuinely don't expose one — we checked the rendered HTML and the embedded JSON-LD structured data on live item pages and found no "listed at," "sold at," or "last updated" timestamp anywhere. Any tool that claims to give you a Mercari Japan sold date is either estimating it from something else or reading Mercari's non-public internal API, which this Actor deliberately does not call (see "What this Actor won't do"). We'd rather ship a smaller, honest set of fields than a field we can't back up. scrapedAt tells you when we observed the item — it is not, and should not be read as, the sale date.

Can I get more than 100 items per keyword? Not in this version — the cap is intentionally conservative while the Actor is new. Run the same keyword again later, or split a broad search into several narrower keywords.

Should I use Japanese or English keywords? Japanese. Mercari Japan's search is built for Japanese text; romanized or translated keywords typically return far fewer or less relevant matches.