Japan's resale market as JSON, including what things actually sold for

Yes - that is the most useful thing this API does for resale pricing. Set status to sold_out and every row you get back is a completed sale carrying the price it sold at, which is what a resale comparable actually is; a live listing only tells you what somebody hopes to get. Measured live on 2026-09-06: a Japanese trading-card keyword with status sold_out returned rows that were 20 of 20 sold_out, and with a price_desc sort the same query came back in 10.5 KB and 1.63 s. Combine it with a category id or a brand id to build a comparables set for one exact kind of item.

Because 15,000 is Mercari's cap, not a count. Mercari returns exactly that number for any keyword with real supply, and it only moves when the result set is genuinely small - a 10,000 to 12,000 yen price band brought it down to 12,901, and a junk keyword returns 0. The response never hides this: total_results comes with total_results_is_estimate set to true on every call, and total_results_capped_at set to 15000 whenever it is sitting on the cap. To actually walk a result set, use next_page_token instead.

New items. It was checked by comparing id sets rather than by trusting the token: pages 1 through 4 returned 20 new ids each with 0 repeats, and 100 rows over five pages gave 97 distinct ids. The small overlap that appears deeper in the stream is Mercari's live index re-ordering under the cursor - new listings pushing rows across a page boundary - not the engine repeating a page; the first two pages never overlap at all. With page_size 120 it pages cleanly to at least 960 rows. The token is Mercari's own opaque cursor and must be passed back as given, not constructed. page_size itself is a hint, not a promise - a 20-row request came back with 14 on one live sold-listing call - so read count.

No, and there cannot be - every Mercari listing is a unique second-hand object, so there is nothing to review. rating, review_count and rating_scale on the item are all null rather than invented. The reputation that DOES exist is on the seller, and product/detail returns it: a numeric star rating that is a real average (measured 0 with no ratings, 4.5 over 13 ratings, 5 over 2,505), the number of ratings behind it, and a good/normal/bad breakdown - which is the part that actually discriminates, because Mercari feedback is overwhelmingly good. Like count and comment count are published under their own names and are deliberately not dressed up as reviews.

Because Mercari runs two id spaces and both are served. A private C2C listing is the letter m followed by 11 digits and lives at jp.mercari.com/item/<id>; a Mercari Shops product, sold by a business, is 22 base62 characters and lives at jp.mercari.com/shops/product/<id> behind a different endpoint entirely. Feeding a Shops id to the private-listing endpoint is a hard 400, so anyone iterating their own search results would hit it: a default search returned 0 to 3 Shops rows in every 60 measured. product/detail reads the id shape and routes accordingly, and both kinds come back with the same key set so nothing downstream has to branch - the fields Mercari does not publish for Shops products come back as explicit nulls. Set listing_type to c2c or shops if you want only one kind.

Every published filter was proved to bite, and the ones that could not be proved were not published. Verified: condition new returned 20 of 20 new; a 50,000 to 60,000 yen band returned 20 of 20 in range; a leaf category id returned 20 of 20 in that category; sold_out returned 20 of 20 sold; price_asc and price_desc were strictly monotone across 20 rows; newest cut the median listing age from 289,545 seconds to 11,084. Filters left out include a coupon flag that returned 9 of the same 10 rows as the control, a size filter with nothing to verify against, and a shipping-method filter whose id space is not the one items report back. This matters because Mercari SILENTLY IGNORES an out-of-range value rather than erroring - an invalid condition id came back with a normal-looking mixed page - so every enum here is rejected up front and re-checked in the response.

Not on its own, and the API says so in the parameter's own description. Buyer-pays is rare on Mercari, and when the filter runs short of rows Mercari backfills the page with Mercari Shops listings, which carry no shipping-payer value at all and were never filtered - measured at 9 matching plus 11 unfiltered in a page of 20. Adding listing_type=c2c makes it 20 of 20. It is the same class of problem as the ignored enum above: a plausible answer to a question you did not ask.

A formatted price string - only a bare integer of yen, so price_display is null and currency is the documented constant JPY. No rating scale: a scan of the whole payload finds no maximum-rating key anywhere, so rating_scale is null rather than an assumed 5. No stock quantity and no competing-offer table, because a C2C listing is one object from one seller - there is nothing to compare. No seller name and no category name on a search ROW, only the ids; product/detail names both. No size - the size field was null on every row measured, in every category tried. And no category directory: there is no endpoint that lists Mercari's categories, so ids are discovered from search rows and from product/detail, which returns the full named path.

Mercari Japan API is a ReefAPI endpoint group for japan's c2c resale marketplace: live and sold listings, prices in yen, seller reputation. It returns live JSON through POST requests under /mercari/v1.

Yes. ReefAPI starts with 1,000 free credits, no card required. Mercari Japan calls use the same shared credit balance as every other ReefAPI engine.

No login to Mercari Japan is needed for the API response. You call ReefAPI with your x-api-key header, and the playground can run live examples before you create a production key.

The page example is captured from a live search call, and production requests fetch live data through ReefAPI rather than a static sample.

Mercari Japan actions currently cost 1 credit per successful call. Failed or blocked calls are free, and all APIs draw from one credit pool.

Yes. Connect ReefAPI once through MCP and your assistant can call mercari actions with the same key, credit pool and JSON envelope used by normal REST requests.