How to Scrape Otodom.pl Polish Real Estate Listings in 2026

Otodom.pl is Poland’s number-one property portal — if a flat in Warsaw, a house near Kraków or a plot in the Tricity is for sale or rent, it’s almost certainly listed there. That makes it the single richest source of Polish real-estate data, which also makes it a popular scraping target and therefore moderately defended. The good news: you don’t need a headless browser to get clean data out of Otodom. Like most modern Next.js sites, it ships its listing data as a structured JSON blob embedded in the page on first render. This guide explains how to read that payload directly, what fields you get, and how to build a fast, browser-free Otodom pipeline.

What’s worth extracting

For each Otodom listing, the embedded data payload exposes a consistent, detailed record:

• Identity — a stable listing ID, the listing detail URL, title and short description.
• Classification — transaction type (sale / rent) and property category (apartment, house, plot, commercial, warehouse, garage, room).
• Pricing — sale price or rent price in PLN, currency, and price per m² (either reported by the listing or computed from price ÷ area). For rentals, czynsz (the monthly administrative/common-area fee) on top of rent.
• Physical — area in m², room count, floor and total floors in the building.
• Location — hierarchical address components (province / voivodeship, city, district, subdistrict, street, postal code) plus GPS coordinates.
• Market — primary vs. secondary market segment (new developer offer vs. resale).
• Seller — agency / company metadata and owner type (so you can tell agency listings from direct-owner ones).
• Media — the full image gallery URLs and an image count.
• Timing — creation and push timestamps for change tracking.

That’s 25–35 fields per listing, enough to build serious market analytics without ever loading a detail page in a browser.

Why you don’t need a browser

Otodom is built on Next.js. When the server renders a search-results page, it embeds the data the React front-end needs as a JSON island in the HTML — the familiar __NEXT_DATA__ script tag (and per-page SSR props). Everything the listing cards display is already in that payload before any JavaScript runs.

That changes the whole engineering approach:

• HTTP fetch, not headless Chrome. You request the search-results URL, locate the embedded Next.js JSON, and parse the listing search payload. No DOM rendering, no waiting for hydration, no Playwright.
• Far cheaper and faster. A browser-based scraper spends seconds per page launching and rendering. An HTTP-only scraper fetches and parses in a fraction of that, at a fraction of the compute cost.
• More stable. The shape of the SSR JSON changes less often than the rendered DOM and its CSS class names. You’re parsing data, not scraping markup.

The trade-off is that Otodom, like any high-value portal, has bot defenses on its endpoints. They’re tuned for abusive traffic, not for polite paginated reads, but at scale you still want a residential Poland proxy to present a local, residential IP and reduce friction. The architecture stays HTTP-only; the proxy is just there to look like a normal Polish visitor.

How the search and pagination work

You drive the scraper with the same filters Otodom exposes in its search UI, encoded into the search URL:

• Transaction type — sprzedaz (sale) or wynajem (rent)
• Property category — apartment / house / plot / commercial / warehouse / garage / room
• Location — voivodeship, city, district
• Price range (PLN) and area range (m²)
• Number of rooms / bedrooms
• Market segment — primary (pierwotny) or secondary (wtorny)
• Owner type, search radius, and sort order

The scraper walks the paginated results, extracts the embedded Next.js JSON from each page, and emits one structured row per listing. Because it’s HTTP-only, it sustains high throughput across many pages and cities.

▶ Run the Otodom.pl Scraper — direct NEXT_DATA parsing, no browser. Filter by location, price (PLN), area, rooms and market; get price, m², czynsz, GPS, address, agency and image gallery per ad.

Schema design for downstream use

When the data lands in your warehouse, you want it shaped for PLN/m² analysis and time-series tracking. A clean per-listing row:

{
  "listing_id": "65412987",
  "url": "https://www.otodom.pl/pl/oferta/...",
  "title": "3-pokojowe mieszkanie, Mokotów",
  "transaction": "sale",
  "category": "apartment",
  "price_pln": 985000,
  "currency": "PLN",
  "rent_pln": null,
  "czynsz_pln": null,
  "price_per_m2": 13680,
  "area_m2": 72.0,
  "rooms": 3,
  "floor": 4,
  "floors_total": 7,
  "province": "mazowieckie",
  "city": "Warszawa",
  "district": "Mokotów",
  "street": "Puławska",
  "postal_code": "02-566",
  "lat": 52.1942,
  "lon": 21.0218,
  "market": "secondary",
  "agency": "XYZ Nieruchomości",
  "owner_type": "agency",
  "image_count": 18,
  "created_at": "2026-05-10T09:14:00Z",
  "scraped_at": "2026-05-22T12:00:00Z"
}

A few schema choices worth making early:

• Always store both reported and computed price_per_m2. Some listings report it; for the rest you compute price ÷ area. Keeping the source explicit avoids comparing apples to oranges in your heatmaps.
• Separate rent_pln from czynsz_pln. For rentals, the headline rent and the monthly common-area fee are different numbers. Conflating them overstates yield and understates tenant cost — a classic Polish-market mistake.
• Keep the full address hierarchy. Voivodeship → city → district → street lets you aggregate at any geographic granularity later.
• Persist created_at and scraped_at. Diffing on these timestamps across runs is how you detect new listings and price changes.

Typical use cases

What customers actually do with Otodom data:

• Market research — build PLN/m² heatmaps and price statistics by voivodeship, city and district.
• Investment screening — compute gross rental yield by pairing monthly rent against sale price per area for comparable flats.
• Lead generation — isolate direct-owner listings (no agency) for buyer-agent outreach, or cluster listings by agency to map portfolios.
• Price tracking — re-scrape on a schedule and diff on the creation/push timestamps to catch reductions and new entries.
• Primary-market monitoring — track new developer offers in the primary segment as they list.
• Cross-city comparison — run the same filters across Warsaw, Kraków, Wrocław and the Tricity to compare markets on one chart.

The common thread is structured PLN pricing at scale. The value is in normalizing thousands of listings into clean per-m² rows you can aggregate, not in any single ad.

Cost math for the managed approach

Because the scraper is HTTP-only, the compute cost per listing is tiny — no browser to launch, no page to render. Under this actor’s pricing, results are emitted at no per-row charge, so the dominant cost is the per-run start fee plus residential Poland proxy bandwidth, and proxy bandwidth on JSON fetches is far lighter than on full browser page loads.

A realistic pipeline — every for-sale apartment in five major Polish cities, re-scraped daily — might be tens of thousands of rows per run. The HTTP-only architecture keeps this comfortably in the low-cost range, where a browser-based equivalent would burn many times the compute and proxy bandwidth.

What you avoid by using a managed actor rather than building your own:

• Reverse-engineering the Next.js payload shape and keeping up when it shifts
• Building pagination with loop detection across thousands of pages
• Sourcing and rotating a residential Poland proxy pool
• Normalizing PLN pricing, czynsz and the address hierarchy

Common pitfalls

A few things to know before committing to an Otodom pipeline, whether you build or buy:

• Czynsz is not rent. Treat the common-area fee as a separate field or your yield math and tenant-cost comparisons will be wrong.
• Primary vs. secondary matters. New developer units and resale flats price very differently per m². Always segment by market before aggregating.
• Payload shape drifts. The embedded JSON structure changes occasionally with Next.js upgrades. A parser pinned to one exact path breaks; resilient extraction is the maintenance burden.
• Proxy geography. A non-Polish IP draws more friction. Residential Poland is the path of least resistance.
• Duplicate cross-postings. The same property can appear under multiple agencies. Dedup on listing ID, and for analytics consider near-duplicate detection on address + area.

Wrapping up

Otodom’s Next.js architecture is a gift: the cleanest Polish property data sits right in the page payload, no browser required. The work is in parsing that payload reliably, paginating at scale, presenting a local IP, and normalizing PLN pricing and czynsz correctly. If you need refreshed Polish real-estate data for analytics, investment screening or lead-gen, a managed HTTP-only actor delivers it far cheaper than a browser-based scraper and keeps the parser green as the payload evolves.

▶ Open the Otodom.pl Scraper on Apify — fast, browser-free, residential-proxy backed. Filter by city, price and market; get clean per-listing rows with GPS and czynsz. Start with Apify’s free monthly credit.