Mercari Japan Unofficial API: Listing and Price Data in 2026

Mercari is the largest consumer-to-consumer marketplace in Japan, and for anyone doing resale, arbitrage, or pricing research it is a goldmine — sneakers, trading cards, cameras, vintage fashion, all priced by individual sellers. It also has no public API. If you want Mercari JP listing and price data programmatically, you are working against an internal mobile/web back end that was never meant for outside callers. This guide is an honest Mercari Japan unofficial API: what the internal surface looks like, the token reality you have to deal with, and how to land listing and price data cleanly in 2026.

The API gap

There is no developer program and no public REST API for Mercari Japan. The official surfaces are the app and the website (jp.mercari.com), both of which talk to internal endpoints intended only for Mercari’s own clients. So:

• There is no key you can request, no documented endpoints, and no terms that contemplate third-party data access.
• The internal search and item endpoints exist (the web client calls them), but they are private contracts that Mercari changes on its own schedule.
• Authentication is not a simple API key. The web/app clients attach short-lived, client-generated tokens to requests — a DPoP-style signed token reality where each request carries a freshly minted, cryptographically bound header rather than a static credential.

Calling this a Mercari Japan unofficial API is accurate only with that caveat: you are leaning on a private back end, and the durable, lower-risk path is often to read the rendered/embedded data the site serves rather than to forge the token dance perfectly.

What data is actually available

From a search or a listing, the fields that matter for resale and pricing work:

• Item core: item ID, name, the price (in JPY), and the item condition (new, like-new, used, and so on — Mercari’s condition grades are central to pricing).
• Status: on sale vs. sold-out. This is the single most important field — Mercari is a sold-listings goldmine because a sold item is a real transaction price, not an ask.
• Seller signals: seller ID/handle and seller rating where surfaced.
• Categorization: category and brand, plus any item attributes the listing carries.
• Media: the thumbnail and gallery image URLs.
• Timestamps: created/updated, which let you reconstruct how long inventory sat before selling.

The sold-vs-active distinction is why people scrape Mercari at all: comparable sold prices are far more useful for valuation than active asks.

How the internal surface works

A credible Mercari Japan unofficial API works with these realities:

• Search returns a paged item list. The internal search accepts a keyword, plus filters for category, brand, price range, condition, and crucially an item-status filter so you can pull only sold or only on-sale items. Results come back as JSON in pages, advanced by a cursor or page token rather than a simple offset.
• The signed-token requirement. Direct requests without the client-generated token are rejected. Reproducing the signing scheme is brittle; it changes. Many robust builds instead render the page (the search results and item pages hydrate from embedded JSON) so the token is produced by the page itself, then read the embedded payload.
• Item detail endpoints return the full listing — description, condition, shipping payer, and seller info — keyed by item ID.
• Everything is JP-locale. Titles, descriptions, brand names, and categories come in Japanese. Plan for UTF-8 and for downstream translation/normalization if your consumers are not reading Japanese.

Be honest about the limits of certainty here: the exact internal paths and signing details shift, so the resilient approach is to consume the embedded page state and treat any raw internal endpoint as something that can move under you.

Rate limits and how to live with them

No published quota — it is a private back end — and Mercari actively defends it:

• Use Japan-resident residential proxies. Requests from foreign datacenter IPs are challenged or blocked quickly; Mercari is a JP-only service.
• Keep concurrency low and add jitter; the token-bound requests make aggressive bursts stand out immediately.
• Warm a session before deep paging, and respect the search-depth cap (deep pagination is limited, as in the UI — narrow by category, brand, or price band to reach more inventory).
• Back off on challenges rather than retrying hard.

▶ Try the Mercari Japan Scraper on Apify — search any keyword and export active and sold listings with prices and condition. No auth required.

A clean output schema

Flatten one row per listing, with status and currency explicit:

{
  "item_id": "m12345678901",
  "name": "ポケモンカード リザードン VMAX",
  "name_translated": "Pokemon Card Charizard VMAX",
  "price_jpy": 18500,
  "currency": "JPY",
  "condition": "used_like_new",
  "status": "sold_out",
  "category": "トレーディングカード",
  "brand": "Pokemon",
  "seller_id": "u987654321",
  "seller_rating": 1240,
  "image_url": "https://static.mercdn.net/item/detail/orig/photos/m123.jpg",
  "item_url": "https://jp.mercari.com/item/m12345678901",
  "listed_at": "2026-05-28T03:10:00Z",
  "updated_at": "2026-06-02T11:44:00Z",
  "scraped_at": "2026-06-07T12:00:00Z"
}

Keep status a tight enum (on_sale / sold_out), store price_jpy as an integer (JPY has no minor units), and carry both the original Japanese name and an optional translation — never overwrite the original.

Use cases

• Resale and arbitrage. Compare Mercari JP sold prices against eBay, StockX, or other markets to find cross-border flips.
• Comparable-sales valuation. For collectibles (cards, watches, cameras), recent sold listings are the real market price for grading and pricing.
• Inventory and demand research. Measure sell-through time (listed-to-sold gap) by category and brand.
• Brand and counterfeit monitoring. Track listings of a brand for fakes and gray-market activity.

Build it yourself vs. a managed actor

The hard part is not parsing — it is the token reality and the JP-only anti-bot environment. Reproducing the signed-token scheme is a moving target, and you need Japan-resident proxies plus session warming to stay unblocked. That is real, recurring maintenance. A managed actor absorbs the token handling, the JP proxies, and the embedded-payload extraction behind a keyword input. For a single curiosity pull, render a few pages yourself; for an ongoing resale or pricing pipeline, the managed route is what survives Mercari’s next change.

Common pitfalls

• Forging the token by hand — it changes and breaks; consume the embedded page state instead.
• Non-JP IPs — they get blocked fast; use Japan residential exits.
• Conflating active and sold — only sold listings are real prices; always carry status.
• Mishandling Japanese text — UTF-8 everywhere, and never discard the original title.
• Treating JPY as decimal — it is integer yen; do not divide by 100.

Wrapping up

Mercari Japan has no public API, only an internal, token-bound back end built for its own clients. The Mercari Japan unofficial API approach reads the public listing and search data the site already serves — leaning on embedded page state rather than forging the DPoP-style token — behind Japan-resident proxies, and always separates sold prices from active asks. Build it yourself for a one-off, or let a managed scraper handle the token reality and JP proxies for a recurring resale or pricing pipeline.

▶ Open the Mercari Japan Scraper on Apify — sold and active listings, JPY prices, and condition grades for any keyword. Pay per listing returned, no key needed.