How to Scrape Boliga.dk Denmark Real Estate in 2026

Boliga.dk is Denmark’s largest real-estate portal, and unlike most property sites it does not hide its data behind an aggressive anti-bot wall. The catch is that there is no public, documented developer API — so if you want the whole market as rows in a spreadsheet, you either click through hundreds of result pages by hand or you talk to Boliga’s own JSON endpoints directly. This guide covers the second path: what Boliga exposes, how its listing API is shaped, and how to pull clean, nationwide property data — including the estate agent behind each listing — without a login or a token.

What’s worth extracting

Boliga carries a rich, consistent record per listing. Once you page through the JSON, each property gives you around 40 fields. Grouped by what you’ll actually query:

• Pricing — asking price and squaremeterPrice (price per m²) in DKK, plus downPayment, net monthly cost (net), monthly expenses (exp), the public evaluationPrice, and the last recorded sale (lastSoldPrice / lastSoldDate).
• Size and layout — living area (size), lot size (lotSize), basement size (basementSize), rooms, floor and buildYear.
• Identity and location — id, url, full address, normalized cleanStreet, city, zipCode, municipality (kommune), plus latitude / longitude for mapping.
• Property classification — human-readable propertyType (Villa, Rækkehus, Ejerlejlighed, holiday home, plot, farm, houseboat) and the raw propertyTypeCode.
• Market signals — energyClass (A–G), daysForSale, createdDate, and boolean-ish isForeclosure / isActive flags to surface value plays.
• Estate-agent identity — agentRegId (registration id), agentDisplayName and isPremiumAgent. This is what turns one property run into a Danish estate-agent lead list.
• Media — image (main photo URL) and imagesCount.

For pure market analysis you mostly need price, size, location and the market-signal fields. For lead generation, agentRegId is the anchor. The README is explicit about one gotcha here, which matters for how you build your lists — see Pitfalls.

How the source actually works

Boliga’s site is a single-page app backed by a clean JSON listing API. The actor reads that endpoint and auto-paginates the full result set of any search — no browser, no headless Chrome, no DOM parsing. That’s why it runs cheap on datacenter proxy: there’s no JavaScript challenge to solve, just a JSON API to page through.

You have two ways to target a search. The first is to hand it a Boliga search URL and let it parse the filters out:

{
  "searchUrl": "https://www.boliga.dk/resultat?zipcodeFrom=8000&zipcodeTo=8260&propertyType=1&priceMin=2000000",
  "maxResults": 800
}

The second is to drive the structured filters directly. The property-type codes are worth memorizing because Boliga uses numeric codes, not names: 1=Villa, 2=Rækkehus, 3=Ejerlejlighed (condo), 4=Fritidshus (holiday home), 5=Andelsbolig (cooperative), 6=Landejendom (farm), 7=Helårsgrund (plot), 8=Villalejlighed, 10=Houseboat, 12=Fritidsgrund. A Copenhagen-condos-by-most-expensive-per-m² query looks like:

{
  "zipCodes": "1050-1499,2100,2200",
  "propertyType": "3",
  "sort": "sqmprice-d",
  "maxResults": 1000
}

zipCodes accepts a single code (2100), a comma list (2100,2200), or a range (1050-1499). Leave every filter empty and you get the newest listings across all of Denmark. sort supports date-d (newest, default), date-a, price-a / price-d, and sqmprice-a / sqmprice-d. There’s also an extraQueryParams escape hatch for advanced Boliga filters like salesDateMin=2024-01-01&energyClass=A appended raw.

▶ Open the Boliga.dk Scraper on Apify — one run returns every listing for a zip, a kommune or all of Denmark, with price, m²-price, energy class, GPS and the estate agent. No login, no API key. Export to JSON, CSV or Excel.

The access reality

The honest friction with Boliga is different from a site like Booking.com or a hardened real-estate portal. There’s no Akamai, no JA4 fingerprinting, no rotating challenge page. The friction is:

• No official API. There’s no documented contract, no versioning, no rate-limit header telling you what’s allowed. You’re reading the same JSON the front-end reads, which means the shape can shift when Boliga ships a redesign. A managed actor absorbs that maintenance.
• Pagination is the real work. A single zip is a few hundred listings; a nationwide search can span tens of thousands. You have to page through the entire result set correctly, respect the API’s page size, and stop at your maxResults cap — set maxResults to 0 for no limit.
• Politeness. Because there’s no published rate limit, the safe move is to pace requests and route through proxy rather than hammer the endpoint from a single IP. Datacenter proxy is enough here — you don’t need to pay for residential.
• DKK only. All prices come back in Danish kroner. There’s no currency parameter; if you want EUR you normalize downstream.

The naive approach — one curl against a result URL — gets you the first page and nothing else, and you’ll misread the pagination scheme within an hour. The value of a managed scraper is that the pagination, proxy and field-normalization logic is solved once.

Example output

One flat row per listing, ready for a spreadsheet or a warehouse. A trimmed sample:

{
  "id": "2089413",
  "url": "https://www.boliga.dk/bolig/2089413",
  "address": "Strandvejen 12, 2. tv, 2100 København Ø",
  "city": "København Ø",
  "zipCode": "2100",
  "municipality": "København",
  "propertyType": "Ejerlejlighed",
  "price": "4295000",
  "squaremeterPrice": "56513",
  "rooms": "3",
  "size": "76",
  "buildYear": "1932",
  "energyClass": "C",
  "daysForSale": "41",
  "isForeclosure": "false",
  "agentDisplayName": "EDC København",
  "agentRegId": "1542",
  "isPremiumAgent": "true",
  "evaluationPrice": "4100000",
  "lastSoldPrice": "3250000",
  "latitude": "55.7158",
  "longitude": "12.5849",
  "scrapedAt": "2026-06-07T12:00:00.000Z"
}

Note that numeric-looking fields (price, size, latitude) arrive as strings. Cast them on ingest if you’re doing math.

Typical use cases

What people actually build on Boliga data:

• Denmark market analysis — track inventory, asking prices, m²-prices and daysForSale across zips, kommuner and property types over time.
• Price-per-m² heatmaps — compare squaremeterPrice between neighbourhoods and cities to map where Denmark is heating up or cooling.
• Investment and foreclosure screening — filter on isForeclosure, low daysForSale, build year and energy class, then compare evaluationPrice and lastSoldPrice against the asking price to find value.
• Estate-agent lead generation — build outreach lists of Danish agents by area, price band or property type using agentRegId + agentDisplayName.
• Price tracking and alerts — re-run on a schedule and diff against the prior dataset to catch new listings and price drops.
• Portals, dashboards and ML — feed a Danish property feed, a BI dashboard or a valuation model from a scheduled run.

The common thread is freshness. A snapshot from last quarter is a curiosity; a daily-refreshed feed across the whole country is sellable infrastructure.

Cost and effort: build vs. managed

Building this yourself is not as painful as beating an anti-bot stack, but it’s not free either. You need to reverse the JSON endpoint, get the property-type codes and zip-range syntax right, implement correct pagination to the tens-of-thousands ceiling, add retry logic, and re-check it every time Boliga tweaks its front-end contract. Call it a day or two for a working MVP plus recurring babysitting.

The managed actor runs on pay-per-result: a per-run start fee plus a fraction of a cent per listing row, with no monthly subscription and no Boliga API fees (there are none to pay). Datacenter proxy keeps runs cheap. For a scheduled Denmark-wide refresh you’re looking at low single digits of dollars per run, and maxResults lets you cap any run inside a budget. The trade-off is the usual one: a managed scraper is opinionated about output schema, but you inherit someone else’s maintenance instead of carrying your own.

Common pitfalls

Specific to Boliga, worth knowing before you commit a pipeline:

• agentDisplayName is sparse, agentRegId is not. The README is explicit: agentRegId is present on virtually every listing, while agentDisplayName is filled only for a subset. Use agentRegId as the reliable join key and treat the name as best-effort enrichment — don’t drop agent-less rows just because the display name is blank.
• Everything is a string. Price, size, coordinates and flags come back as strings (e.g. isForeclosure is "false", not a boolean). Parse them explicitly.
• DKK, no conversion. Prices are Danish kroner with no currency switch. Normalize to EUR/USD downstream if you’re comparing across countries.
• lotSize is often 0. Condos and apartments legitimately have no lot, so a 0 there is data, not a bug — don’t filter it out as missing.
• De-dupe on id. If you run overlapping searches (a zip range plus a kommune), the same listing can appear twice. The Boliga id is the stable unique key.
• GDPR on agent data. Listing data is public, but agentRegId and agentDisplayName are personal/business data. If you build outreach lists, you own compliance with GDPR and Boliga’s terms.

Wrapping up

Boliga is one of the friendlier real-estate sources to extract — no anti-bot wall, a clean JSON API, and an unusually rich record that even carries the selling agent. The only real engineering is correct pagination to the tens-of-thousands ceiling and keeping up with front-end changes. If you want the whole Danish market on a schedule without owning that maintenance, use the managed actor.

▶ Run the Boliga.dk Scraper on Apify — a nationwide run yields tens of thousands of listings with price, m²-price, energy class, foreclosure flag, GPS and estate-agent id. No login, no API key. Export to JSON, CSV, Excel or HTML. Start on Apify’s free monthly credit.