Immowelt Property Scraper (Germany)

Scrapes apartment and house listings from Immowelt — Germany's #2/#3 property portal (AVIV Group). ImmoScout24 (Germany's #1) is already flagged in this portfolio's research as saturated (6+ independent sellers already scrape it); Immowelt is a different company, untouched here.

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

The one thing you need to know before using this

No JSON data source exists anywhere on this site — checked in priority order: no JSON-LD carrying listing fields, no __NEXT_DATA__, no Apollo state, no RSC flight stream. Both search and detail pages are plain server-rendered HTML with a rich, stable data-testid attribute vocabulary — this actor is pure HTML parsing (selectolax), the same tier as property24-properties-scraper/adp-jobs-scraper elsewhere in this portfolio.

There is no HTTP-only pagination. Immowelt's real "next page" route is an AJAX endpoint its own robots.txt disallows (Disallow: /liste/getlistitems). Every search therefore returns one fixed batch (~30 listings, 40 for houses) — the same situation this portfolio already solved for quintoandar-properties-scraper. Use the Cities list to fan out across multiple places rather than expecting depth pagination within one city.

What you get

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

PROPERTY — one row per listing

List cards already carry price, address, room count and floor area. Turn on Fetch listing detail pages to also attach propertyDetail, which adds the full description, an itemised features list, energy certificate data (year built, condition, heating type) and a detailed price breakdown (notary fees, transfer tax, buyer's commission) — none of which are on the search results page.

SEARCH_SUMMARY — one row per (city, estate type, buy/rent) query

How many listings the single batch contained, and segmentResolved — whether the city/type/transaction combination actually matched anything.

ERROR — one row per input that failed

So every entry in Cities maps to at least one output row.

Input

Field	What it does
Cities	German city slugs (berlin, muenchen, hamburg) — one search per entry, each returning its own fixed batch
Property type	apartments or houses — applies to every city
Buy or rent	applies to every city
Fetch listing detail pages	adds description/features/energy/price-breakdown (off by default — one extra request per listing)
Max properties per city	caps how many of the single batch to keep — there is no deeper page to fetch

Example

{
  "cities": ["berlin", "muenchen", "hamburg"],
  "estateType": "wohnungen",
  "transactionType": "kaufen",
  "includePropertyDetails": true
}

Notes on reliability

• Filters are genuinely honest, a rare case in this portfolio's REAL_ESTATE family: an unrecognised city answers a clean HTTP 410 (Gone), and an unrecognised property-type path segment answers a clean HTTP 404 — neither silently widens to a national/parent baseline the way most other targets in this portfolio's REAL_ESTATE family do.
• ?page=N is completely inert (verified live: page 1 and page 2 return byte-identical listing ids) — see "no HTTP-only pagination" above for why, and use multiple cities instead.
• A de-listed property answers a clean HTTP 410 — the search row is still emitted, with propertyDetail: null.
• No WAF or bot-mitigation gate was observed — 8 TLS profiles across both surfaces, all clean, cold.

Output envelope

Every record carries _input, _source and _scrapedAt. Since there is no upstream JSON object to pass through verbatim (see above), each PROPERTY row's fields are this actor's own explicit extraction from the page's data-testid structure — not a renamed/reshaped copy of a JSON blob, because none exists.

See CRAWLING_METHOD.md for the full reverse-engineering trail.