L logiover
ecommerce · May 30, 2026 · 9 min read

How to Scrape Mercari Japan Listings by Keyword in 2026

Scrape Mercari Japan listings by keyword — price in JPY, condition, brand, sale status, seller and photos — with no login, no cookies and no API key.

If you want to scrape Mercari Japan at any kind of scale, you quickly run into the same wall: mercari.jp is built for one shopper browsing one screen at a time, in Japanese, from a Japanese IP. There is no bulk export, no public CSV, and the official app/site fights automated access. Yet Mercari is Japan’s largest consumer-to-consumer marketplace, and the data sitting inside it — live prices in JPY, sold comps, brand and condition breakdowns, seller reputation — is exactly what proxy-buying services, resellers and pricing analysts need. This guide explains what that data is worth, how a keyword-driven scraper pulls it cleanly, and the exact fields you get back.

Why Mercari Japan data is valuable

Mercari Japan is a C2C marketplace, which makes it structurally different from a retailer like Amazon or Rakuten. Listings are posted by individual sellers, priced by hand, and sold once — so the marketplace is a giant, constantly-updating record of what real people in Japan will actually pay for used and new goods. Three audiences care intensely about that:

  • Proxy buying services — services that buy Japan-only items on behalf of overseas customers live or die on Mercari coverage. They need to surface matching listings for a customer’s keyword, show price in JPY, condition and sale status, and detect when something sells out so they stop quoting it.
  • Resellers and arbitrage — anyone flipping Japanese sneakers, trading cards, vintage clothing, cameras, anime goods or game hardware onto eBay, StockX or Mercari US is running a price gap. To find that gap you need both the live ask and the sold comps — what equivalent items actually closed at.
  • Pricing and market research — brands, analysts and data teams benchmark resale value, track sell-through velocity, and monitor grey-market and counterfeit activity by brand and category.

The common thread is that a single screenshot of one search is useless, but a structured, refreshed feed of thousands of listings per keyword is a genuine asset. That is the gap a scraper fills.

Why scraping mercari.jp is its own engineering problem

Scraping Mercari is not like scraping a server-rendered public archive. The mercari.jp search results are served by a signed internal API, and the site is geo-served from Japan. A naive HTTP GET from a US data center gets you nothing useful. Two things make a managed scraper work:

  • Signed API access, not a browser. Instead of driving a headless Chromium (slow and expensive), the scraper talks directly to Mercari’s public search API and signs every request with a freshly generated DPoP (ES256) token. There is no account, no cookies and no developer key involved — it mints its own request signature each time.
  • Residential proxies in Japan. Because Mercari is served from Japan, residential proxies give the most reliable access. This is pre-configured for you, so you do not have to source or rotate Japanese IPs yourself.

The payoff is that there is no login, no cookie jar to expire, and zero account ban risk — it reads only public search data. And because there is no headless browser in the loop, it stays fast and cheap even when you are pulling thousands of records.

Input: keyword search and filters

The scraper is keyword-driven. You hand it a list of search terms and optional filters, and it runs one search per term, paginating each until the term is exhausted or your cap is reached.

The fields that matter:

  • searchTerms (array, required) — the keywords to search, e.g. nintendo, pokemon card, supreme. One full search per term.
  • status (enum)on_sale (default), sold_out, or all. This is the switch that gives you sold comps: set it to sold_out to pull completed sales.
  • sort (enum)SORT_SCORE (best match), SORT_CREATED_TIME (newest), SORT_PRICE, or SORT_NUM_LIKES.
  • priceMin / priceMax (integer, JPY) — price-range filter; 0 means no bound.
  • categoryId / brandId / itemConditionId (array) — optional Mercari id filters to narrow to a category, brand or condition.
  • fetchDetails (boolean) — when on, also fetches each item’s detail page for the full description plus seller stats. Default false.
  • maxItemsPerTerm (integer) — cap per keyword; 0 = unlimited.
  • maxResults (integer) — global cap across all keywords; 0 = unlimited.
  • proxyConfiguration (object) — residential proxy, pre-configured and recommended.

Example input

{
  "searchTerms": ["nintendo", "pokemon card"],
  "status": "on_sale",
  "sort": "SORT_CREATED_TIME",
  "priceMin": 1000,
  "priceMax": 50000,
  "fetchDetails": false,
  "maxItemsPerTerm": 1000
}

How pagination works

For each keyword, the actor queries Mercari’s search API and walks the result page token — Mercari paginates with an opaque cursor rather than numbered pages — pulling page after page until either the search result set is exhausted or your maxItemsPerTerm / maxResults cap is hit. This is how a single term yields thousands of listings instead of just the first screen. Because pagination is token-based, you control depth purely with the two cap fields rather than fiddling with page numbers.

Run the Mercari Japan Scraper — point it at any keyword and pull every matching mercari.jp listing with price, condition, brand and seller. No login, no API key, no ban risk. $5 per 1,000 listings.

Output: exact fields you get back

Each listing is written to the dataset as one clean record. Here is a realistic example:

{
  "id": "m12345678901",
  "url": "https://jp.mercari.com/item/m12345678901",
  "name": "Nintendo Switch 本体 有機ELモデル ホワイト",
  "price": 32000,
  "currency": "JPY",
  "status": "STATUS_ON_SALE",
  "itemConditionId": "2",
  "categoryId": "1234",
  "brandId": "5678",
  "brandName": "Nintendo",
  "sellerId": "987654321",
  "itemType": "ITEM_TYPE_MERCARI",
  "thumbnail": "https://static.mercdn.net/c!/w=240/thumb/photos/m12345678901_1.jpg",
  "photos": ["https://static.mercdn.net/item/detail/orig/photos/m12345678901_1.jpg"],
  "created": 1717400000,
  "updated": 1717500000,
  "searchTerm": "nintendo",
  "scrapedAt": "2026-06-04T10:00:00.000Z"
}

Field reference

FieldDescription
id / urlMercari item id and the direct listing link
nameListing title (in Japanese)
price / currencyPrice in JPY
statusSTATUS_ON_SALE or STATUS_SOLD_OUT
itemConditionIdMercari condition id (1 = new … 6 = poor)
brandId / brandNameBrand id and name, when present
categoryId / itemTypeMercari category and listing type
sellerIdSeller id
thumbnail / thumbnails / photosImage URLs (thumbnail plus full photo array)
created / updatedListing timestamps (Unix seconds)
searchTermThe keyword that produced this record
scrapedAtCapture timestamp

When you turn on fetchDetails, each record additionally carries description, sellerName, sellerNumSellItems, sellerNumRatings and sellerScore — the full item text plus seller reputation. That detail pass hits each item’s page individually, so it is slower; pair it with a sensible maxItemsPerTerm rather than running it unbounded.

A couple of schema notes worth internalizing before you wire this into a warehouse:

  • status is your sold-comp flag. Filter rows on STATUS_SOLD_OUT to build a completed-sales table, separate from live asks.
  • Keep photos as an array. Even single-photo listings come through as an array, so don’t flatten it to a string — you will regret it the first time a multi-photo listing arrives.
  • created/updated are Unix seconds. Convert to timestamps on ingest if you plan to chart sell-through velocity.

Use cases in practice

Proxy buying services

A proxy-buying operation can run a fixed set of customer keywords on a schedule, keep only on_sale listings, and surface fresh matches with price, condition and photos. Because every record carries status, the service can automatically retire a listing the moment it flips to STATUS_SOLD_OUT, so customers are never quoted on something that’s already gone.

Resellers and arbitrage

Run two passes for the same keyword set: one with status: "on_sale" for the live ask, one with status: "sold_out" for sold comps. The gap between the sold-comp median and your destination marketplace’s price is your margin, and SORT_NUM_LIKES plus created/updated give you a read on demand and velocity. Layer in brandId and itemConditionId to keep your comps apples-to-apples — a “new” Nintendo Switch and a “poor”-condition one are not the same comp.

Price and market research

Benchmark resale value for any brand or product line by pulling a wide keyword set with generous caps, then aggregating price by brandName, categoryId and itemConditionId. Tracking the same query weekly turns a static benchmark into a trend line, and monitoring odd brand/category combinations is a cheap way to flag counterfeit and grey-market activity.

Cost math

Pricing is $5 per 1,000 listings, pay-per-result. So a reseller monitoring 20 keywords at up to 1,000 listings each is 20,000 listings — about $100 for a full snapshot — and capping each term at 200 instead drops that to 4,000 listings, or roughly $20. Because depth is controlled entirely by maxItemsPerTerm and maxResults, you tune spend precisely: a daily refresh of a tight keyword set is cents per run, while a one-off deep pull across a whole category is a known, bounded cost. Turning on fetchDetails does not change the per-result price, but it does add request volume, so use it where seller stats and descriptions actually earn their keep.

FAQ

Do I need a login, cookies or API key to scrape Mercari Japan?

No. The actor signs its own DPoP (ES256) tokens for Mercari’s public search API. There is no account, no cookies and no developer key, which means there is no Mercari account to get restricted or banned — it reads public data only.

How many listings can I get per keyword?

Thousands. The scraper paginates the full public search result set with Mercari’s result-page token. You control depth with maxItemsPerTerm (per keyword) and maxResults (global cap across all keywords).

Can I get sold-out listings and sold prices for comps?

Yes. Set status to sold_out to pull completed sales, or all to get both live and sold listings in one run. Sold-out records are how you build comparable-sales (comp) data for pricing.

Can I filter by price, brand or condition?

Yes. Use priceMin / priceMax for a JPY price range, and brandId, categoryId and itemConditionId to narrow to a specific brand, category or item condition.

How do I get item descriptions and seller ratings?

Turn on fetchDetails. It fetches each item’s detail page for the full description plus seller stats — sellerName, sellerNumSellItems, sellerNumRatings and sellerScore. It is slower because it hits each item individually, so combine it with a sensible per-term cap.

Why does it use residential proxies?

Mercari is served from Japan, so residential proxies give the most reliable access. The default proxy configuration is set up for you — you don’t need to source or rotate Japanese IPs yourself.

Run the Mercari Japan Scraper — keyword search across mercari.jp with price, condition, brand, sold-out comps and seller stats. Export to JSON, CSV or Excel. $5 per 1,000 listings.

Wrapping up

Mercari Japan is one of the richest resale datasets in the world, but it is locked behind a Japanese-language, geo-served, signed API that punishes naive scraping. A keyword-driven, login-free scraper turns it into a clean feed — live asks, sold comps, brand and condition breakdowns, seller reputation — that proxy-buying services, resellers and pricing analysts can build a product on. If you need to scrape Mercari Japan listings at scale without touching an account or maintaining the DPoP-signing and Japanese-proxy plumbing yourself, run it as a managed actor and keep your focus on the margins, not the maintenance.

Related guides