at home Japan Rental Listings

Search at home (athome.co.jp) - a major Japanese property portal - and get one flat row per rental room listing: rent, management fee, deposit, key money, layout, floor area, floor, building age, nearest stations, agent and images. Built for a new-property or price-drop alert per city: point it at a search URL, sort by newest, and re-run it on a schedule.

Not athome.lu. Several actors already on the Apify Store named "athome" (haketa/athome-lu, logiover's athome actor, sian.agency's athome-lu) scrape athome.lu, the unrelated Luxembourg property site. This actor is Japan's athome.co.jp only, and refuses athome.lu URLs outright.

Scope: rental (chintai) searches only

athome.co.jp runs several sections under similar-looking URLs, and they are not the same application:

Path	What it is	Supported here
/chintai/<pref>/<city>/list/	Rentals	Yes
/mansion/chuko/<pref>/<city>/list/, /kodate/chuko/..., /tochi/...	Resale purchase listings	No
/mansion/shinchiku/<pref>/<city>/list/	New-build condos for sale	No

Probed 2026-09-28: /chintai/... and /mansion/chuko/... are both the Angular app this actor's parser reads, but they answer different backend calls with different JSON shapes (rent-living/property-list for rentals versus sell-living/bukken/list for resale) - a resale row is not "a rental row with different numbers", it is a different record entirely. /mansion/shinchiku/... turned out not to be the Angular app at all: it is an older, separate template with no serverApp-state script on the page, so there is nothing there for this actor's parser to read. Building the resale side properly is a second actor's worth of work, not a flag on this one, so this actor covers rentals only. A listUrls entry outside /chintai/ is refused with an explanation rather than silently returning nothing.

Input

Field	Type	Default	What it does
listUrls	array	—	One or more https://www.athome.co.jp/chintai/<prefecture>/<city>/list/ URLs, exactly as your browser shows them (filters and all). Page numbers already in the URL are ignored - this actor pages from 1 itself.
sort	select	recommended	newest is athome's own 新着順 (registration order) - what a new-listing alert should run on. Also: rent low/high, floor area, built date new/old, station, address, layout - every order athome's own sort dropdown offers.
maxItems	integer	200	Stops after this many rows, across all listUrls combined.
proxyConfiguration	proxy	Apify datacenter	See Proxy below.

What one row contains

One row is one room listing (bukkenNo) inside one building. A building advertising three rooms is three rows; the same physical room re-listed by a second agency is a fourth row with a different id, because it is a separately payable listing a renter could contact on its own.

Field	Notes
property_id, url	athome's listing id and its detail page.
property_type	athome's own building category, e.g. 賃貸マンション / 賃貸アパート.
building_name, name, room_number	The building's name, this room's full listing title, and its room number.
address	The building's address, as athome prints it.
stations, nearest_station_walk_minutes	Every "line, station, N min walk" string athome shows for the building, plus the shortest walk time parsed out of them.
rent_jpy	Monthly rent in yen. athome quotes rent as a bare 万円 (10,000-yen) figure - "32.2" - this is that figure × 10,000, never the raw string.
management_fee_jpy	Monthly management/common-area fee in yen. Null when athome shows － (none charged).
deposit_raw, deposit_jpy, deposit_months, deposit_free	Deposit (敷金). deposit_raw is athome's own string - either "Xヶ月" (a multiple of the rent) or "Y万円" (a flat amount) or waived. deposit_months is set only when the raw string is a month multiple; deposit_jpy is set either directly, when athome already quotes yen, or as rent_jpy × deposit_months when it quotes months - a real multiplication of two numbers athome printed, not a guess at one it withheld. deposit_free mirrors athome's own waived-deposit flag.
key_money_raw, key_money_jpy, key_money_months, key_money_free	Key money (礼金), same shape as the deposit fields above.
layout, floor_area_m2	e.g. 2LDK, and floor area in square metres.
floor, floor_raw, total_floors, total_floors_raw	This room's floor and the building's total floor count, parsed to an integer, with athome's original string kept alongside because the parse does not distinguish a basement level (B1階).
built_year, built_month, age_years, age_months, built_raw	Parsed out of athome's single "2022年7月(築4年3ヶ月)" string: the completion year and month, and the age athome itself states as of when the page was captured.
structure	Always null. athome's building-construction-material field (RC, wood, steel) is shown on the listing's own detail page but never appears in the search-result JSON this actor reads.
thumbnail_url, image_urls	Absolute image URLs.
posted_at	Always null. Not carried by the search JSON at all - see below.
is_new	athome's own "new listing" badge - the closest thing the search JSON carries to a posted date, and the field a new-listing alert should actually watch.
agent_name, agent_url	The listing agency for this specific room row. A building's rooms are routinely listed by several different agencies, each its own row with its own agent.
search_url	Which of your input URLs this row's search came from.

Why structure and posted_at are null, not guessed

Both are real athome data points, visible on a listing's own detail page - but the search-result JSON this actor reads (rent-living/property-list/first-view) never sends either one. A blank or a fabricated date would read as a measurement; null says, correctly, "athome did not send this here."

How it fetches

athome.co.jp's rental search is an Angular app rendered server-side: every list page embeds the resolved search result as JSON inside <script id="serverApp-state">, keyed by the internal BFF call that produced it. This actor reads that JSON directly rather than parsing the rendered HTML table, and pages by walking .../list/, .../list/page2/, .../list/page3/, ... - confirmed against the site's own pagination links.

Proxy

Default is Apify datacenter. athome runs bot defense that answers a refused address with HTTP 200 and a "認証中" ("verifying") interstitial page rather than a 403 - this actor treats that shape as a transient failure and rotates the exit address, the same as a real block. Measured 2026-09-28 probing this actor's build from a single non-proxied address: the first handful of requests to different /chintai/... and buy-section paths were served normally, then the address started getting the interstitial on every further /chintai/... request for the rest of that session - a real, escalating, per-address block. If a run starts failing with a bot-defense message, switch to Residential, or Residential pinned to JP. Apify's residential proxy pool cannot be measured from outside the platform (its addresses refuse requests made off-Apify), so this actor was not able to directly compare datacenter vs. residential vs. JP-residential open rates before shipping; the guidance above is the fallback path if datacenter starts getting blocked in your own runs, not a claim that residential is proven better.

Billing

Pay per event, all-in: platform usage - compute, bandwidth, proxy - is included in the event price. You are never billed for it separately, and the run is never switched to charge you Apify's own usage costs on top.

• $0.0021 per row (listing-scraped), charged once per room listing written to the dataset.
• $0.002 actor-start per run, charged only once your input has been validated - so a run that fails on bad input costs you nothing.
• A run stops as soon as your spending limit is reached rather than continuing to work unpaid; everything already written stays in the dataset.

Compared to the existing athome.co.jp actor on the Store

solidcode's athome.co.jp actor charges $0.003 per result. This actor's $0.0021 per row is roughly 30% under that.