Platform · Otodom

Otodom Data Scraping

A large share of this market is new build, and a development listing can represent two hundred units. Counting it as one is the error.

Otodom data scraping collects Polish property listings, asking prices, status and attribution. The structural feature: new-build development is a large share of this market, and a development listing frequently represents many units rather than one property. So primary and secondary market listings have to be separated before anything is counted.

Every property page in this set says a listing is not a property. In Poland's primary market the ratio can be one to two hundred.

Get a free sample See sample data

Free pilot on your own Otodom list, returned in 24 hours. No card, no trial clock — and you keep the sample data either way.

otodom.jsonl LIVE FEED

{"portal":"otodom","market_segment":"primary", "listing_id":"ot-44120","developer_name":"developer-a", "unit_count":212, "asking_price":489000,"price_is_from":true, "phase_identifier":"as published"} {"market_segment":"secondary","unit_count":1, "price_is_from":false, "note":"one listing = 212 units. the other = 1. pooling them understates supply badly"} {"price_is_from":true,"prior_from_price":459000, "excluded_from_average":true, "caution":"from-price up 30k. usually means the cheap units SOLD, not a price rise"}

3 of 684,110 listing rows · Polandprimary separated BEFORE counting · schema v1.0

Independence and trademarks. Actowiz Solutions is not affiliated with, endorsed by or connected to Otodom or its owners. Otodom and related marks belong to their respective owners, used here only to name the publicly accessible source this service collects from.

Our Data Powers

B2C Marketplace

amazon

D2C + Marketplace

NYKAA

D2C + Marketplace

Walmart

FMCG Marketplace

udaan

Food Delivery

Uber Eats

Quick Commerce

blinkit

Taxi Aggregator

Uber

E-Commerce

Tmall

Otodom at a glance

How we handle Otodom specifically

Platform-specific handling, not a generic retail template pointed at a different domain.

Portal: Otodom — Poland
The feature: Large new-build share
Consequence: A development listing is many units
So: market_segment separates primary from secondary
Unit counts: Where published. Never estimated
Prices: From-prices on developments. Flagged as such
Asking price: Not a transaction price
Refresh: Daily; development phases release on a schedule

Platform specifics

Primary and secondary are different products

These are the reasons a Otodom dataset needs its own handling rather than a shared retail schema.

A development listing is not one property

Primary-market listings represent developments — a building or scheme with many units, released in phases. Secondary-market listings represent one property.

Counting them together understates supply, sometimes dramatically.
A development's price is a from-price, representing its cheapest available unit.
Phases release over time, so a development reappears with new inventory.
Price movement means something different — a development's from-price rising may mean cheap units sold rather than prices increasing.

That last point matters more than it sounds. A rising from-price on a development is frequently a sell-through signal, not a price signal, and a series that pools primary and secondary reads one as the other.

market_segment separates them on every record. unit_count is captured only where published and left null otherwise — we do not estimate units from a description.

From-prices are flagged

price_is_from is true on development listings, and they are excluded from average asking-price figures by default rather than quietly included.

Polish conventions, and what we do not collect

Area and price per square metre

Price per square metre is the standard Polish reference figure and appears on most listings. We capture it as displayed and compute our own alongside, flagging disagreement.

On developments the displayed figure frequently corresponds to the from-unit rather than to the scheme, so psm_basis records which.

Development phases

phase_identifier where published and relisting_event where a development reappears with new inventory — because a reappearing development in a feed without this looks like a new listing.

Status

Transitions as timestamped events. On developments a listing disappearing may mean a phase sold out rather than a scheme completing, and the portal does not say which. disappearance_reason is not_determined.

What we do not collect

Unit counts estimated from a description. Published or null.
Sell-through or units sold. Not published.
Developer financial data. Not published.
Vendor, buyer or enquirer data. Never.

Scope

What we collect on Otodom, and what we do not

The right column matters more than the left. Anyone can list fields; the limits are what tell you whether the dataset will hold up.

✅ What we collect

market_segment separating primary from secondary on every record
unit_count only where published, null otherwise
price_is_from flagged, with from-prices excluded from averages by default
psm_basis recording whether price per square metre is scheme or from-unit
phase_identifier where published
relisting_event where a development reappears with new inventory
Status transitions as timestamped events
disappearance_reason as not_determined
price_is_asking as a constant true

❌ What we do not, and why

Primary and secondary listings pooled in a supply count
A unit count estimated from a listing description
A from-price included in an average asking price
A rising from-price read as a price increase
Sell-through, developer financials or enquirer data

Core Otodom fields

The full dictionary is agreed during scoping. These are the fields specific to this platform.

Field	What it is on this platform
portal / listing_id / voivodeship / city	The listing and where it is
market_segment	primary or secondary. Separated before counting
unit_count	Where published. Never estimated
asking_price / price_is_from / price_is_asking	The figure, and what kind it is
price_per_sqm_displayed / price_per_sqm_computed / psm_basis	Theirs, ours, and which unit
area_sqm / area_basis	With the basis
phase_identifier / relisting_event	So a returning development is not a new listing
developer_name / agency_name	Commercial entities
status / status_changed_at / disappearance_reason	Events, and what we cannot know
address_precision	As published. Never sharpened
observed_at	Timestamp

Use cases

What teams do with Otodom data

Polish supply counting done correctly

Primary and secondary separated before counting, since a development listing can represent hundreds of units and pooling them understates supply dramatically.

Development sell-through signals

From-prices flagged with phase identifiers, so a rising from-price can be read as cheap units selling rather than as a price increase.

Secondary market price series

A clean secondary-only series with development from-prices excluded by default, which is the comparable figure against other markets.

Developer activity tracking

Developments by developer with phase events, as commercial entities rather than individuals.

The 24-hour sample — run on your sources, not ours

Send us a Otodom item or category list. We run real collection against it and return the output within 24 hours, with the platform-specific fields populated so you can check them yourself rather than take our word for it.

Real extraction from your actual sources
Returned within 24 hours
Coverage and QA note included
You keep the data either way
No card, no trial clock
Named engineer on the call

Get my free sample Book a 20-min scoping call Reply within one business day. Reference calls available under NDA.

How we engage

Three ways to engage us

Same collection pipeline and QA underneath. The difference is who holds the schedule and how the data reaches you.

Managed service (most common)

We own the collection, the QA and the delivery. You receive clean data on a schedule and never touch a scraper.

Dedicated engineer assigned to your account
Site changes fixed by us, not reported to you
Scheduled delivery to your warehouse or S3
Named contact on Slack or email

Best fit: Teams who need the data, not the infrastructure.

API access

The same collection pipeline exposed as an authenticated REST endpoint your systems query directly.

On-demand and scheduled endpoints
Rate limits agreed to your load profile
Sandbox keys for integration testing
Versioned schema with deprecation notice

Best fit: Product and engineering teams building on live data.

One-time or project extraction

A defined pull for a specific question — market sizing, diligence, a pitch, a one-off audit.

Fixed scope agreed in writing upfront
Single delivery with full QA report
Methodology documented for your records
Converts to managed if you want continuity

Best fit: Research, strategy and diligence work with a deadline.

Pricing

Every engagement is quoted individually, because the honest answer depends on your scope: how many sources, how many records, how often, and how the data reaches you. We scope it with you, run a free pilot on your own sources, and then quote a fixed monthly figure — no per-request metering and no overage billing when volumes move. Request a quote and you will have a number after one call.

Otodom is usually collected alongside its competitors

Almost nobody buys a single platform in isolation. Otodom data becomes useful when it sits next to the competitor set on one schema, refreshed on one schedule, so a price index or availability comparison is genuinely like-for-like.

That is what real estate data covers, and a Otodom-only engagement can be expanded into it without rebuilding. If you already know you need several platforms, start there instead — it is the same pipeline and usually the better scoping conversation.

FAQ

Otodom data scraping: frequently asked questions

Platform-specific questions, including what cannot be collected here.

Because a development listing represents many units released in phases, while a secondary listing represents one property. Counting them together understates supply, sometimes dramatically.

They also behave differently — a development's price is a from-price representing its cheapest available unit.

Because a from-price tracks the cheapest available unit. If the cheap units sell, the from-price rises with no repricing at all.

That is a sell-through signal rather than a price signal, and a series pooling primary and secondary reads one as the other.

Where it is published, yes. Where it is not, the field is null — we do not estimate unit counts from a listing description.

Not published, and we do not infer it. A from-price movement is suggestive rather than a count, and treating it as one would put a model in a quantity field.

We record a relisting event with the phase identifier where published. A returning development in a feed without this looks like a new listing, which inflates new-supply figures.

We quote individually on geography, listing volume and refresh. Primary-market coverage adds phase tracking, which is worth scoping deliberately.

One scoping call, a free pilot within 24 hours, then a fixed monthly quote. Request a quote.

See real Otodom data before you commit to anything

Send us an item or category list. We return the output within 24 hours with the platform-specific fields populated.

Get a free sample Talk to an engineer

Free pilot, no card, no obligation. If we cannot collect a field you need on this platform, the sample shows you that too.

Hear It Directly from Our Clients

Watch how businesses like yours are using Actowiz data to drive growth.

▶

1 min

★★★★★

"Actowiz Solutions offered exceptional support with transparency and guidance throughout. Anna and Saga made the process easy for a non-technical user like me. Great service, fair pricing!"

Thomas Galido

Co-Founder / Head of Product at Upright Data Inc.

▶

2 min

★★★★★

"Actowiz delivered impeccable results for our company. Their team ensured data accuracy and on-time delivery. The competitive intelligence completely transformed our pricing strategy."

Iulen Ibanez

CEO / Datacy.es

▶

1:30

★★★★★

"What impressed me most was the speed — we went from requirement to production data in under 48 hours. The API integration was seamless and the support team is always responsive."

Febbin Chacko

-Fin, Small Business Owner