The same apartment appears on four portals, under two agencies, with three different floor areas and two different asking prices. ScrapeWise extracts every listing, resolves them to one property, keeps the price history, and hands you rows you can model yield on.
Multi-agency listing is the norm, not the exception. Counted raw, a market of 3,000 properties reads as 5,000 units of supply. Worse, the duplicates are not evenly spread — desirable stock is listed more widely, so the distortion lands hardest exactly where the analysis matters.
Portals show today's asking price and nothing else. The number that predicts a negotiation — was this listed at EUR 199,000 six weeks ago and cut twice since — exists only if someone captured the listing before the cut. It cannot be recovered retroactively.
Gross, net, living and usable area get published in the same field with no label. A yield model built on unreconciled area figures produces price-per-square-metre numbers that are confidently wrong, and the error is invisible in the output.
A sold property often stays up for weeks. Without tracking first-seen, last-seen and status transitions, time-on-market is unmeasurable and the apparent inventory includes stock nobody can buy.
Yield needs both, matched to comparable stock in the same micro-location. Collecting them from separate portals without a shared location and attribute model leaves you comparing a 2-room rental in one district to a 3-room sale in another.
Per 1,000 listing pages extracted — a whole city's inventory costs less than an analyst hour
Ready-made site endpoints, plus any regional property portal you point us at
Free requests on every new account — pull a district and check the rows before committing
Tell us the city or districts, which portals carry the inventory there, and whether you need sale, rental or both. Matching tolerances and inclusion rules are agreed before a single page is collected.
Every listing is extracted independently, then resolved to a property on address, floor, rooms and area. Each run is diffed against the previous one so price cuts, new inventory and status changes are captured the day they appear.
Delivered as JSON, CSV or straight to your warehouse, with property-level totals and listing-level detail together. Feed it into yield models, comparables or acquisition screens and re-run the same scope on any cadence.
This is the actual sequence behind the resolution above — a two-room Tallinn apartment appearing on four portals under two agencies, with three stated floor areas and one price cut nobody would see from a single snapshot.
Each portal is collected on its own terms: asking price, stated area, room count, floor, building year, address as published, agency, listing reference and the date the portal claims it went live. Nothing is merged at this stage. Four listings go in as four rows, each carrying the URL it came from, because a reconciliation you cannot audit is a reconciliation nobody will trust.
Matching runs on the combination that actually identifies a property — address or cadastral reference where published, plus floor, room count, area within tolerance and building. Agency listing references match two of the four immediately. The fourth states 45 m² against 48.2 m² elsewhere, inside the tolerance band but flagged: it still resolves to PR-10482, and the conflict is carried on the row rather than silently averaged away.
Because the property was already being tracked, the row carries what the portals do not show: first seen 63 days ago at EUR 199,000, cut to EUR 189,000 on day 23, and one portal still advertising EUR 195,000 with a last-modified date 41 days old. Time-on-market, the cut history and the stale outlier are all derived from the extraction history — none of it is readable from today's page.
Property extractions rarely fail on the asking price. They fail on identity, on area, and on time — and each of those errors survives into the model looking exactly like a correct number.
Address strings differ by portal, and many deliberately obscure the house number until enquiry. Identity is built from what is stable: cadastral or land-registry reference where published, then address plus floor, room count, area and building year together. Any one of those alone over-merges.
Gross, net, living and usable area are published interchangeably. Where the portal labels the basis it is captured; where it does not, the figure is kept as stated and marked unlabelled rather than assumed. Price per square metre is computed only on a stated basis, never on a guessed one.
Today's asking price is one field. The negotiation signal is the sequence: original asking price, each change, the date of each change and the cumulative reduction. It exists only because the listing was observed over time, which is why history cannot be backfilled after the fact.
First seen, last seen and status transitions separate live inventory from listings a portal simply never took down. Without them, time-on-market is unmeasurable and apparent supply includes stock that has already sold.
Every listing collected lands in one of three states. A property dataset that does not distinguish them cannot support a supply count, let alone a valuation.
First time this property has been seen. It contributes one unit to supply, carries its own price history from the moment it was first observed, and holds the listing it was resolved from as evidence.
Matched to a property already resolved, usually the same agency syndicating or a second agency on the same instruction. It adds a price point and a channel but not a unit of supply. Kept visible, because how widely a property is advertised is itself a signal.
Same address and floor, but an area or room count outside tolerance, or two materially different asking prices on the same day. Held rather than merged or dropped, because silently averaging 45 m² and 50 m² produces a price per square metre that is wrong in a direction nobody can see.
You define the market, the portals and the property types. You receive deduplicated property rows with asking prices, normalised attributes and the price history the portals do not publish.
The country, city or districts you are tracking. Defined as portal search URLs, a district list, or a bounding area you approve before extraction starts.
EE — Tallinn: Kristiine, Põhja-Tallinn, KesklinnNational portals plus the regional and agency sites that actually carry inventory in that market, including agency websites where listings appear before syndication.
kv.eecity24.eerightmove.co.ukagency sitesBoth sides are needed for yield. Sale and rental listings are extracted into the same attribute and location model so comparable stock can actually be compared.
On by default. Each run diffs against the previous one, so price cuts, status transitions and days on market accumulate. History starts the day tracking starts — it cannot be backfilled.
Daily is what makes a price cut visible within a day of it happening. A one-off snapshot gives you inventory and prices but no history and no time-on-market.
One row per listing, keyed to one property, 16 columns each
Delivered by REST API, CSV export or straight into your data warehouse. Property-level totals and listing-level detail arrive together, so a supply count can always be traced back to the listings that produced it.
One row per listing, each carrying the property it resolved to — which is what lets you count supply and channels from the same dataset. Five listings, two properties, one conflict held back.
| matched_property_id | portal | address_normalised | rooms | area_sqm | asking_price | days_on_market | resolution |
|---|---|---|---|---|---|---|---|
| PR-10482 | portal-a.ee | Kristiine, Tallinn — 4th floor | 2 | 48.2 | EUR 189,000 | 63 | resolved |
| PR-10482 | portal-b.ee | Kristiine, Tallinn — 4th floor | 2 | 48.0 | EUR 189,000 | 63 | duplicate |
| PR-10482 | portal-d.ee | Kristiine, Tallinn — 4th floor | 2 | 45.0 | EUR 189,000 | 63 | conflicting — area 45.0 vs 48.2 |
| PR-10730 | portal-a.ee | Põhja-Tallinn — 2nd floor | 3 | 71.4 | EUR 244,900 | 9 | resolved |
| — | portal-c.com | Kristiine, Tallinn — 4th floor | 2 | 50.0 | EUR 195,000 | — | stale — last modified 41 days ago |
Listings are resolved across portals and agencies before anything is counted, so supply figures reflect properties rather than advertisements. The duplicates are retained as channels, because how widely a property is marketed is a signal in its own right.
Every run is diffed against the last, so original asking price, each cut, cumulative reduction and days on market accumulate on the property. This is the negotiation signal, and it exists only from the moment tracking starts.
Floor area, room count, floor and building year are normalised across portals, with the measurement basis recorded where the portal states it and conflicts flagged where they disagree. Price per square metre is computed on a stated basis, never a guessed one.
Stop counting advertisements as supply. ScrapeWise resolves every listing to a property, keeps the price history the portals discard, and delivers rows your yield and comparables models can actually use.
Everything you need to know about extracting property listing, price and rental data with ScrapeWise.
Any public listing site. ScrapeWise ships 36 ready-made site endpoints and adds new ones on request, which in property is usually necessary — the portal that decides a national market is rarely one of the global names. Agency websites matter too, because listings frequently appear there before they syndicate.