Boligsiden Property Scraper (Denmark)

Scrapes houses and apartments for sale from Boligsiden.dk — Denmark's #1 property portal. Nordic coverage in this portfolio was Hemnet (Sweden) only; Denmark was untouched.

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

The one thing you need to know before using this

No WAF, no bot-mitigation gate of any kind was found — 7 TLS profiles across both search and detail pages, all clean, cold, no warmup needed. The one real engineering challenge is the data layer: Boligsiden renders via Next.js App Router RSC streaming (self.__next_f.push(...)), not __NEXT_DATA__, and the listing array sits nested inside a large React-element tree rather than as a plain top-level list — this actor walks that tree looking for the enclosing object that carries the results, not for the array itself. See CRAWLING_METHOD.md §5 for the details.

What you get

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

PROPERTY — one row per listing

Search rows (listing) already carry price, full address, coordinates, room count, living area, energy label, days-listed and the listing agent — among the richest search-only payloads in this portfolio. Turn on Fetch listing detail pages to also attach propertyDetail, which adds the one field genuinely absent from search: the property's free-text description.

SEARCH_SUMMARY — one row per kommune (or the whole country)

Pages fetched, rows returned, a best-effort total, and kommuneResolved — whether the requested municipality actually matched something upstream.

ERROR — one row per input that failed

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

Input

Field	What it does
Kommunes	Danish municipality slugs (koebenhavn, aarhus, …) — leave empty for the whole country as one query
Fetch listing detail pages	adds the free-text description (off by default — search already has almost everything)
Max properties / max pages per search	pagination caps — Boligsiden pages honestly, no clamp/repeat trap
Max concurrent requests / Min seconds between requests	can be raised more freely than most actors here — no gate observed

Example

{
  "kommunes": ["koebenhavn", "aarhus"],
  "includePropertyDetails": true,
  "maxItems": 100
}

Notes on reliability

• No WAF observed — a rare case in this portfolio's REAL_ESTATE family. Residential proxy pinned to Denmark is still the default, as this portfolio's standard baseline for a single-country site, not because a gate was found.
• An unrecognised kommune fails clean, not silently-wrong: Boligsiden does not fall back to the national baseline for a bad municipality slug — the entire results structure is absent from the page, and this actor reports kommuneResolved: false with zero rows rather than guessing.
• Pagination is genuinely honest: ?page=N really advances (verified: 0 id overlap between consecutive pages), and a page past the real end answers a truly empty list — no clamp-back-to-page-1 trap like several other actors in this portfolio have to work around.
• estimatedTotalListings is best-effort, parsed from page copy, not a structured field — confirmed live to change per kommune (not just reused from the national figure), but not gated on for any pagination logic.
• A de-listed detail page answers a clean HTTP 404 — the search row is still emitted, with propertyDetail: null.

Output envelope

Every record carries _input, _source and _scrapedAt. Upstream field names pass through verbatim under listing (and propertyDetail when requested) — no renaming.

See CRAWLING_METHOD.md for the full reverse-engineering trail, including the RSC flight-stream parsing approach and what was NOT verified this session (kommune slug enum, property-type filtering).