Rumah123 Property Scraper (Indonesia)

Scrapes houses, apartments, land and shop-houses for sale or rent from Rumah123 — Indonesia's #1 property portal, part of the PropertyGuru group but running its own older codebase (a different stack than propertyguru-properties-scraper elsewhere in this portfolio, which covers Singapore/Malaysia/Thailand).

Public data only. No login, no cookies, no browser.

What you get

Three record types share one dataset, told apart by recordType.

PROPERTY — one row per listing

Search rows (listing) carry name, address, bedrooms, bathrooms, floor size, coordinates and a thumbnail — Schema.org ItemList data, straight from the search page. With Fetch full property details on (the default), each row also gets a propertyDetails object:

• ldJson — price (offers.price, IDR), seller/agent name and profile URL, the full photo gallery, description, geo
• specs — land size, building size, condition/renovation year, bedrooms, bathrooms, garage/carport, floor count, certificate type (SHM/HGB/etc.) — parsed from a server-rendered HTML table the JSON-LD does not carry

SEARCH_SUMMARY — one row per location searched

How many pages were fetched, how many properties matched, and — if you set a price or bedroom filter — how many matched before that client-side filter was applied.

Input

Field	What it does
Jual / sewa	for sale or for rent
Property type	rumah (house) or apartemen (apartment) — see note 3 below on why tanah/ruko are not offered
Locations	one search per entry: jakarta-selatan, bandung, surabaya… human spellings are slugified for you
Property URLs	scrape specific listings directly, skipping search (full URL required — see below)
Min / max price (IDR)	client-side filter, forces detail-fetch on
Min bedrooms	client-side filter, works with or without detail-fetch
Max properties / max pages per location	pagination caps
Fetch full property details	off = fast listing-only crawl, 1 request per ~9 properties

Example

{
  "transactionType": "jual",
  "propertyType": "rumah",
  "locations": ["jakarta-selatan", "bandung"],
  "minPrice": 500000000,
  "minBedrooms": 3,
  "maxItems": 200,
  "includePropertyDetails": true
}

Things this actor is honest about

1. Price and bedroom filters are applied client-side, not sent upstream. Rumah123's robots.txt explicitly disallows crawling with minPrice=, bedroom=, sort= and similar query parameters for generic user agents (it grants a more permissive rule set to a named group of AI crawlers — ClaudeBot, GPTBot, etc. — but this actor runs as a generic browser- impersonating client like every other actor in this portfolio, so it honours the stricter rule). Setting minPrice/maxPrice/minBedrooms filters the parsed dataset after fetching instead of changing the request — same result for you, zero disallowed requests. Every SEARCH_SUMMARY row reports matchedBeforeClientSideFilter so you can see how much was filtered out.

2. Price only exists on the detail page. The search page's JSON-LD never carries price, so minPrice/maxPrice automatically force Fetch full property details on even if you left it off — otherwise the filter would silently keep zero rows.

3. tanah (land) and ruko (shop-house) are not offered. Both return HTTP 200, but their search page's only JSON-LD is a single generic RealEstateListing page description — no per-listing array to iterate. Individual parcels would need HTML-card scraping, a genuinely different extraction path not built this session, so these two are deliberately left out of the input schema rather than shipped broken. rumah/apartemen both carry a proper ItemList with one entry per listing.

Notes on reliability

• No WAF challenge. Serves data cold on every TLS profile tested (5 profiles × home page, plus every search/detail/bogus-path combination tried with chrome131).
• Runs unattended. No human-captured session, no expiring token.
• Unknown location or property type fails cleanly as not_found — a clean HTTP 404, never a silently-wrong nationwide baseline (unlike Immoweb/Otodom/SUUMO elsewhere in this portfolio, all of which have a silent-widen trap on bad filters).
• No upstream pagination ceiling found. page=999 on a narrow search still returned fresh, different listings rather than clamping to the last real page (the Bayt trap) or going empty (the OnTheMarket ceiling) — so maxPages is this actor's own safety valve, not a discovered limit.
• Residential proxy by default on cloud runs.
• Failures never vanish. A listing withdrawn mid-crawl degrades that one row (_detailError); every input maps to at least one output row.

Output envelope

Every record carries _input, _source and _scrapedAt. Upstream field names pass through verbatim under listing (search) and propertyDetails.ldJson (detail) — no renaming. _source is S1-jsonld-search for listing-only rows and S1-jsonld-search+S2-jsonld-detail once details are attached.

Direct-mode propertyUrls requires the full URL — Rumah123's path embeds an SEO slug (.../jakarta-selatan-tebet/rumah-baru-.../hos42193485/) that cannot be reconstructed from the numeric id alone, unlike some other actors in this portfolio.

See CRAWLING_METHOD.md for the full reverse-engineering trail, including the robots.txt AI-crawler-group finding and the specs-table extraction approach.