Funda.nl Scraper — Dutch Property Listings, Photos, 38 Fields

Scrape property listings from Funda.nl, the largest real estate portal in the Netherlands — houses and apartments, for sale and for rent, in Amsterdam, Rotterdam, The Hague, Utrecht, Eindhoven and every other Dutch city.

38 fields per property, including photo URLs, price per m², energy label, full geo hierarchy and days on market. No login, no cookies, no browser needed.

Empty results, and why you will not get them here

A scraper built on CSS selectors fails quietly. When Funda changes its markup, or answers an automated request with a block page, you do not get an error — you get an empty table, or a column of empty values, and you find out later.

This Actor is built the other way round:

• it reads the data Funda already renders into the page, so a redesign of the visual layout does not change what it returns;
• it goes through residential proxies with polite delays and retries every page;
• at the end of every run it prints how many pages failed and how many rows it skipped, and warns you when a promised field came back mostly empty. You never have to guess whether the file is complete;
• you pay per listing returned. A run that finds nothing costs you the Actor start fee of $0.00005 and nothing else.

Quick Start

1. Open funda.nl, set your filters
2. Copy the address of the results page (not a single listing)
3. Paste it into searchUrls and press Start

The default input works out of the box: homes for sale in Amsterdam.

{
  "searchUrls": ["https://www.funda.nl/zoeken/koop?selected_area=amsterdam"],
  "maxItems": 1000
}

Why this one does not break

Most scrapers read the page with CSS selectors. When the site changes its markup, they silently return nothing.

This Actor reads the data the server already renders into the page — Funda is built on Nuxt, and the full result set ships inside the page as structured data. There are no CSS selectors anywhere in the code.

It goes one step further: the listing array is located by its shape — the set of fields every record must have — rather than by a fixed path into the payload. A framework upgrade that moves the data elsewhere does not break extraction.

Two more consequences:

• No browser. Plain HTTP requests, so runs are fast and compute is cheap
• Typed fields. Numbers arrive as numbers, dates as ISO timestamps

A failed page is retried three times with backoff and never aborts the run. A malformed listing is skipped, not the page around it. Every run writes a RUN_STATS record with the real failure rate — you can audit it yourself.

Output

One row per listing:

Field	Notes
id, url	Stable listing id and direct link
type	apartment, house, …
title	Street, number and suffix
price, currency, marketingType	BUY / RENT
priceCondition, priceType	e.g. kosten_koper
pricePerSqm	Calculated for you
livingSpace, floorAreaMin, floorAreaMax	m²
rooms, bedrooms	Numbers, not strings
street, houseNumber, postcode, city
quarter, district, municipality, province	Full Dutch geo hierarchy
preciseAddress	Whether the address is a verified BAG address
daysOnMarket	Days since publication
publishedAt	ISO 8601
energyEfficiencyClass	A, B, C …
constructionType, zoning, status	resale / new build, residential, …
realtorCompany, realtorId	Agency office — see below
country	Always NL
listingKind	Listing kind as the portal classifies it
imageUrls	Full-size photo URLs, ready to download
imagesCount	How many photos this listing has
sourceUrl, scrapedAt

The three things that go wrong with property scrapers

These are the complaints you will find under other Funda scrapers in this Store. Here is what this Actor does about each of them.

"It stopped working." Most scrapers read the rendered page with CSS selectors. The portal ships a new layout and they return nothing — often silently. This Actor reads the structured data the server already puts inside the page, so a visual redesign does not break extraction. On top of that a health check runs every morning, so a real break is found before a customer runs into it.

"Not fetching all records" / "pagination is not working." Every page is retried, and the retry covers parsing, not just the network. The run reports its own failure rate in RUN_STATS: if any page was lost you will see it, instead of quietly getting a shorter file.

"Huge amount of billing for unknown reason." You are charged per listing written to the dataset, not per request. maxItems is a hard stop. Turn on skipWithoutPrice and rows with an empty price are dropped before billing. A container restart cannot cause double charging — run state is persisted.

No personal data

This Actor does not return the estate agent's personal contact — no names, phone numbers or email addresses — even though they appear in the source page. Only the agency office name is included, which is business information.

If you need personal contact data, this is not the right Actor, and under GDPR you would need your own lawful basis for processing it.

Limits — what this Actor does not do

• Search result pages only. Full listing detail pages are not fetched
• Netherlands (funda.nl) only
• No listing photos
• No price history. daysOnMarket comes from the listing's own publication date

Pricing

$2.49 per 1,000 listings — $0.00249 per listing — plus $0.00005 per Actor start. Platform usage (compute and proxy) is included in that price and is not billed to you separately.

A run that returns nothing costs nothing beyond the Actor start.

Cost control

Set Max listings before you press Start and the run's cost is fixed in advance: 1,000 listings is $2.49, 250 listings is $0.62. The Actor stops exactly at that number, on every plan, and writes a RUN_STATS record with what it actually did. Nothing here depends on your plan tier — the behaviour on the Free plan is the same as on any other, just bounded by the credit the plan gives you.

Development

$npm test    # regenerates the fixture and runs offline parser tests, no network

Tests cover the Nuxt payload hydration, shape-based record lookup, GDPR filtering, incomplete records, and a deliberately malformed listing.