SUUMO Rentals — new listings by ward

Runs a SUUMO rental search (chintai) and returns one flat row per room, not per building. SUUMO's own results page groups rooms into "cassettes" - one card per building, with a table of every room currently available in it - and a building with four vacant rooms produces four rows here, sharing the building's address, access lines, age and floor count, and differing in the room-level fields: floor, rent, layout and area.

Input

Give it either a search URL, or a prefecture code plus one or more ward/city codes - both can be combined in one run.

Field	Type	Default	What it does
searchUrls	array	—	One or more rental search URLs copied straight from suumo.jp, e.g. https://suumo.jp/jj/chintai/ichiran/FR301FC001/?ar=030&bs=040&ta=13&sc=13113 (東京都渋谷区, Shibuya). Every filter already on the URL - rent band, layout, "no key money" - survives; only the page number is driven by this actor. Recommended for anywhere outside the Kanto region, since a pasted URL already carries the right region code.
prefectureCode	string	—	SUUMO's own ta code, e.g. "13" for Tokyo.
cityCodes	array	—	SUUMO's own sc codes (ward/city), e.g. "13113" for Shibuya-ku. One search per code, sharing prefectureCode and areaCode.
areaCode	string	"030"	SUUMO's own region grouping, the ar parameter. "030" is Kanto, which covers every prefecture this actor was checked against. A search outside Kanto needs its real code - read one off a URL copied from the site, or use searchUrls instead.
sortNewest	boolean	true	Ask SUUMO for its own "新着順" (newest-first) order before paging. Turn off to keep whatever sort a pasted URL already carries.
maxItems	integer	100	Stop after this many rooms across every search in the run.
proxyConfiguration	object	Apify datacenter	See Proxy below.

What one row contains

Field	Notes
room_id, building_id, detail_url	room_id is SUUMO's own bc query parameter on the detail link - the billing key, unique per room. building_id is the jnc_... path segment; several rows share it when a building has several vacant rooms.
building_name	The cassette's title, as SUUMO prints it. On a building SUUMO has no name for, it prints the nearest station, floor count and age instead (e.g. "ＪＲ山手線 原宿駅 10階建 築7年") - that is genuinely what the page shows, not a parsing gap.
building_type	賃貸マンション / 賃貸アパート / 賃貸一戸建て, as printed - never translated.
address, access	access is a list of "<line>/<station> 歩<N>分" strings, one per line SUUMO lists; never padded with blanks.
building_age_years, building_age_raw	0 for a cassette marked "新築" (brand new) - a real age, not a missing one.
floors_above, floors_below, floors_raw	floors_below is null for an ordinary "N階建" building, not zero - SUUMO does not print "0 basement floors" at all.
room_floor, room_floor_raw	Negative for a basement level (SUUMO prints "B2階" for the second basement floor). Null when SUUMO prints "-", which it does for a house let as a whole rather than floor by floor.
rent_jpy, admin_fee_jpy	Whole yen. admin_fee_jpy is null for SUUMO's "-" (no management fee charged) - never 0, which would claim SUUMO stated a fee of zero.
deposit_jpy / deposit_months / deposit_raw, and the same three for key money	SUUMO usually quotes these in 万円 (man-yen), which lands in the _jpy column; it occasionally quotes them as a number of months of rent instead (e.g. "1ヶ月"), which lands in the _months column instead. The _jpy column is never computed from months - that would be a number SUUMO did not itself print. _raw always carries the text as shown.
layout, area_m2	間取り (e.g. "3LDK", "1K") as printed, and 専有面積 in square metres.
building_image_url, room_image_url	The building's own exterior photo and this room's own photo/floor-plan image - the real URLs, read out of SUUMO's lazy-loading markup rather than the 1x1 placeholder it ships in src.
is_new	True only when SUUMO itself marks the room's checkbox "newarrival". SUUMO prints no listing date at all, so this flag - not date math - is the only "new" signal on the page.
source_url	The exact search URL this row was read from, filters and all.

How it pages and sorts

The search is one server-rendered page, /jj/chintai/ichiran/FR301FC001/?ar=<region>&bs=040&ta=<prefecture>&sc=<city>. Pagination is the page query parameter; newest-first sorting is po1=09, read off the sort dropdown's own <option value="09">新着順</option> on the results page. A pasted search URL keeps every other filter it already carries

• only page, and po1 when newest-first was asked for, are added or overwritten.

Proxy

Apify datacenter is the default, and it answered this search with real results. Residential also works, but only when pinned to Japan (apifyProxyCountry: "JP"): an unpinned residential exit gets SUUMO's own "アクセス集中に関するお詫び" (access congestion apology) page - served on a plain HTTP 200, indistinguishable from a real 200 by status code alone. This actor detects that page by its text and treats it as a block, retrying from a different exit rather than reading it as an empty result.

Billing

Pay per event, all-in: $0.00059 per room, plus a small actor-start fee. Platform usage - compute and proxy - is included in that price; you are not billed for it on top. That undercuts competitor solidcode's SUUMO actor, at $0.00084 per result, by about 30%. The run-volume leader in this category, jungle_synthesizer, charges $0.01 per result.

• listing-scraped is charged once per room row, deduplicated globally across every search in the run - a room seen on two overlapping searches, or on two pages of the same search, is billed once.
• actor-start is charged only after your input parses, so a run that fails on a typo costs nothing.
• A run stops as soon as it reaches your spending limit rather than continuing to work unpaid; everything already pushed and charged stays in the dataset.