Japan's biggest local classifieds board, as one JSON API

A free item, and on this site that is the whole point: ジモティー's goods section is literally "selling / giving away". The site's own counters prove there is no third state — 32,059,984 second-hand ads in total, 6,909,491 at 0 yen and 25,150,494 priced, which add up to the total exactly, with nothing left over. So a 0 comes back as price_jpy 0 with price_kind free, never as null and never hidden. Set free_only to true for giveaways only (6,909,491 ads) or false for priced ads only (25,150,494). In the five spaces that genuinely publish no money — events, classes, pets, services, community — price_jpy is null and price_kind is not_priced, which is a different answer and is labelled as one.

Because Jmty prints one "most important" line per row and it means eleven different things. Measured on the first page of every space on 2026-10-02: goods print "0円" or "70,000円"; used cars print "1,150,000円64,000km 2009年" — price, mileage and year run together; property prints "2.2万円", a monthly rent in units of 10,000 yen; part-time jobs print "時給1,500円" or "日給10,160円"; full-time jobs print "年収4,500,000円" or "月収190,000円"; help requests print "報酬：10.000", typed by hand; and events print "開催日:10/1-10/31", classes print a city name, pets print "オス 0才2ヶ月", services and community print a station name. headline is that line, verbatim, always. price_jpy, price_display and price_basis are only filled where the line really is money, so you never get a station name served to you as a price.

It is converted, and we checked it against a second page of the site rather than trusting our own arithmetic. 万 means 10,000, so 7.5万円 is 75,000 yen — and the poster's own profile page prints that same ad as "75,000円" in plain yen. We compared three ads across three spaces in both runs: goods 6,000 against 6,000, property 75,000 against 75,000 and 85,000 against 85,000, used car 320,000 against 320,000. Three for three in each run. Across 220 sampled rows, price_jpy matched the string Jmty prints on the row 101 of 101 times where a price exists, with zero mismatches. price_display always carries the source's own text next to the number so you can check any row yourself.

Jmty injects them, and this API removes them and tells you how many. Every eighth row of a list page is a staffing-agency job ad fed in from a partner site, carrying an hourly wage where the price would be — on page one of a goods search there were 7 of them, and up to 16 on a used-car page. They are not Jmty ads, they have no Jmty ad id, and left in they would put "時給1,500円" into a sofa search. They are dropped and counted in dropped_partner_tiles. Separately, Jmty injects up to two paid-placement ads above the result window; those are real Jmty ads, so they come back in their own promoted[] array with promoted_count, and listings[] holds exactly the 50 organic rows the page's own counter claims.

Fifty organic rows per page, and it is fixed — measured at exactly 50 on the first page of all eleven spaces and on every filtered search across two runs. Paging stops at page 1,000: page 1,000 returns its 50 rows and page 1,001 is a real HTTP 404, not a silent repeat, so 50,000 ads are reachable per filter set. The API returns page_ceiling and reachable_rows on every response next to the site's own total so the gap is visible rather than surprising. Consecutive pages can share a row or two — Jmty re-floats refreshed ads, so page 1 and page 2 of the same search shared 0 ids in one run and 1 of 50 in the other, with no duplicates inside a page.

Every filter we expose was measured against the same-run unfiltered control, and only the ones that moved the total are offered. From a control of 32,059,984 goods ads: keyword 921,446 · prefecture=tokyo 5,838,002 · category=fur 7,388,851 · price band 1,000-2,000 yen 5,561,375 · free_only 6,909,491 · priced-only 25,150,494. From the 7,388,851 furniture control: genre 1245 (chairs) 491,337 · city 276 (Adachi-ku) 52,985 · station 2,418. From the 5,838,002 Tokyo control: online payment only 386,312. Keyword plus a price floor: 921,446 to 13,967. Property with a 20,000-40,000 yen rent band: 3,273,329 to 557,486. Twelve for twelve. One filter the site's own form offers is deliberately NOT exposed: delivery_method left the total at 5,838,002, exactly the unfiltered figure, so it is accepted and ignored — and a handle that does nothing is worse than no handle.

You never have to guess one. categories takes a group and returns that space's category slugs with their Japanese names and, under each, the numeric genre ids search accepts — 20 categories and 235 genres in the goods space alone. locations returns all 47 prefectures with their romanised slug and the 1,246 city and ward ids underneath them. Both are live reads of the site's own search form, not a frozen snapshot. Every search row also echoes the ids it matched, so you can go finer from any result.

No, and the API refuses instead of guessing. Jmty's URL carries one location level, so asking for both would silently drop one — a filter that quietly becomes a different question is worse than an error. Send prefecture plus either city_id or station_id. A city or station filter also needs a category, because the site answers 404 for a city filter on a bare space, and the API says exactly that rather than reporting the site's 404 as something mysterious.

The full description instead of the snippet, every photo, the map coordinates, the inquiry and comment counts, the ad's status, and the attribute block Jmty publishes for that specific kind of ad — which is different in every space: mileage, model year, frame number and inspection status for a used car; rent, management fee, deposit and key money, layout and floor area, floor, building age and address for a flat; pay, company name, address and working pattern for a job; sex, age, neutering, vaccination and why the animal needs rehoming for a pet. We counted them on one live detail per space: 9 attributes on a property ad, 7 on a pet ad, 6 on a service, 4 on an event. It also adds the poster's profile and up to twenty other ads they have live. An id taken from search resolved to the same record — same id, same title, same price — on every detail call in both runs.

What the ad page and the profile page themselves show, unmodified: display name, profile link, the good, neutral and bad review counts separately (one sampled poster had 185 good, 10 neutral, 6 bad), their rating, how many ads they have posted, their self-written profile text, their profile photo, and the verification badges Jmty grants — SMS verified, ID verified, company documents verified, business account, antique-dealer licence and real-estate licence. The seller action opens the profile page on its own and adds their registration date, the area they live in and their stated occupation. 🔴 That page lists ten of their ads however many they have — one sampled account declared 3,648 posts and the page showed ten — and Jmty publishes no seller-ad feed, so listings_sampled tells you what you actually got. For everything a poster has live in one space, use search instead.

Only where Jmty itself prints one on the public ad page, and then exactly as printed. Most ads have none — the field came back null on the large majority of details we sampled — but some posters, typically classes and businesses, put a number in the ad and the API returns it rather than pretending it is not there. Nothing is fetched from behind a login or a click-to-reveal.

You get NOT_FOUND with a message saying the ad does not exist in that space or has been removed, never a blank success you have to interpret — measured on both runs with a nonsense id. An ad that is still on the site but closed or deleted by its poster is a different thing and is treated as an answer, not an error: it comes back as a normal record with status set to closed or deleted and the site's own message, because "this is gone" is information you asked for. A search that genuinely matches nothing returns ok with zero rows and the site's own total of 0.

You need the space it lives in as well, and the API says so instead of failing vaguely. A Jmty ad URL is /{prefecture}/{group}-{category}/article-{id}, and the id is global — the same id fetched through a deliberately wrong prefecture and a deliberately wrong category returned the identical ad, same title and same price, on every attempt in both runs — but the space is load-bearing: asking for a goods id as a job ad is a 404 on the site itself. So pass the url that search returns (always works), or pass listing_id together with group and category. Ask with listing_id alone and you get MISSING_PARAM naming exactly what else to send.

No, and we would rather say that than offer a knob that does nothing. Jmty's list pages carry no sort control at all — no dropdown, no sort link, no ordering text — and the two separate "cheapest" and "ranking" pages it does have are different page types that return no rows in the result grid. So the order is Jmty's own, roughly newest-first, and every row carries created_label and updated_label so you can order them yourself.