Real estate
Turn fragmented listings into a traceable view of the property market.
Unify public residential, commercial, land, and specialist listings without flattening what they mean. Keep property identity, listing episode, asking terms, status, observed changes, and source evidence distinct from the start.
Public listing evidence, not ownership or transaction truth. A listing observation is not a sale, appraisal, rental outcome, ownership record, or regulated decision input by itself; your team retains valuation, underwriting, investment, lending, insurance, housing, and compliance decisions.
Decision workflow · real estateReady
01
Define the property universe
Geographies, asset types, sources, listing states, and observation cadence.
02
Separate entity from episode
One property can have multiple portals, agents, reposts, and asking-price histories.
03
Preserve what is known
Source precision, match confidence, missing reasons, and time remain explicit.
Decision coverage
Property teams need listing history without losing source evidence.
Public listing observations can support market intelligence, comparable research, acquisition, leasing, marketplace operations, and data products. They do not replace deeds, transactions, internal asset data, inspections, appraisals, or regulated decisions.
01
Market research & strategy
Measure visible supply as it changes.
Which public sale, rental, commercial, or land listings appear, change, and disappear across locations, property types, sources, and time?
Listing count and mix
Displayed asking terms
First and last observed
02
Valuation & underwriting
Build inspectable comparable inputs.
Which public listings share the location, property type, size, configuration, attributes, and observation window required for a defensible comparable set?
Normalized property attributes
Price or rent per area
Match and geo precision
03
Acquisitions, development & site selection
Find market movements worth reviewing.
Where are new sites, land, commercial assets, asking-price changes, or long-observed listings appearing in the target market?
New and changed listings
Location and asset type
Listing age and asking trend
04
Pricing, revenue & leasing
Compare like-for-like asking terms.
How do displayed sale prices, rents, concessions, fees, and unit features differ across a defined competitive set and observation period?
Asking price or rent
Fees and concessions
Unit and amenity context
05
Brokerage, listing & marketplace operations
Resolve duplicates and listing state.
Which listings describe the same property, which are reposts, and where are public status, agent, office, media, or content details inconsistent?
Property and episode identity
Duplicate and repost cues
Observed, missing and failed states
06
Data products, analytics & AI
Supply current records with evidence attached.
Which source-linked property and listing observations belong in search, alerting, research, modeling, analytics, or AI workflows?
Stable schema and history
Evidence and parser version
Confidence and exception state
Public-source coverage
Map the market before defining the dataset.
Coverage is a named combination of geographies, source families, page objects, property types, fields, and refresh windows. Representative pages are tested before a source enters production scope.
Source families
Pilot Residential marketplaces Sale, long-term rental, new-build, room rental
Pilot Commercial & land portals Office, retail, industrial, agricultural, development
Pilot Specialist listing surfaces Auctions, classifieds, home-share, niche assets
Pilot Direct & eligible public records Builders, brokerages, managers, planning or assessor sources
Approved property brief
Page objects
01 Search & category Visible inventory, pagination, filters, ranking context
02 Listing detail Asking terms, attributes, status, description, media
03 Property & participant Building, development, agent, office, manager
04 History & public context Price events, open houses, eligible planning or transaction pages
Scope states
Documentado
General page access, browser rendering, proxy behavior, and supported response options described in current product documentation.
Primeiro piloto .
Every real-estate source, schema, geography, address precision, geocoding approach, cross-portal match, history rule, field set, and cadence.
Não padrão
Private MLS or authenticated accounts, internal transaction systems, resident dossiers, tenant or owner profiling, occupancy inference, valuation, or lending decisions.
Public availability does not remove privacy, housing, discrimination, copyright, database-right, source-term, retention, or jurisdiction review.
Inspectable property-data contract
Keep the property, listing episode, observation, and evidence separate.
A URL is not a property identity, a repost is not necessarily a new asset, and a missing page is not proof of a transaction. The record model keeps each claim at the right level.
01 · Property entity
Which physical asset is described?
Property reference, normalized address and unit, source geography and precision, category, type, rooms, living and lot area with units, attributes, and match state.
02 · Listing episode
How was it offered on this source?
Source listing ID and URL, sale, rent or auction intent, public agent or office fields, first and last observed, published or updated time, repost state, description, and media.
03 · Observation
What did the page display at collection time?
Displayed status, asking price or rent, currency and period, price per area with derived flag, public fees or concessions, captured time, observed state, and missing reason.
04 · Evidence & quality
Can the record be explained later?
Source, evidence reference, parser and schema version, field lineage, identity cues, confidence, validation state, exception reason, and delivery batch.
property_observation.json v1 · illustrative
{
"property": {
"property_ref": "prop_7f2",
"address_precision": "street",
"type": "apartment",
"match_state": "exact"
},
"listing_episode": {
"source_listing_id": "L-2841",
"intent": "sale",
"first_observed_at": "2026-07-14T09:12Z"
},
"observation": {
"displayed_status": "active",
"asking_price": 286000,
"currency": "EUR",
"observed_state": "observed",
"captured_at": "2026-07-30T09:12Z"
},
"evidence": {
"source_url": "…",
"schema_version": "1.0"
}
}Illustrative schema only. Final fields, provenance, retention, match thresholds, and acceptance rules are contracted per source and use case.
Listing lifecycle
Resolve property → listing episode → observation.
The sequence prevents three expensive errors: counting the same property twice, treating a repost as uninterrupted history, and turning a missing observation into a claimed market event.
Illustrative entity-resolution path Evidence retained
01
Resolve the property Exact IDs first, then normalized address, unit, coordinates, type, size, rooms, and other approved cues.
02
Resolve the listing episode Keep source IDs, seller or agent, published time, media, and repost cues distinct for each public offer.
03
Append an observation Record the asking terms, displayed status, source evidence, observed state, and capture time without rewriting history.
04
Route uncertainty Exact, candidate, needs review, separate, excluded, not observed, and failed remain operationally different.
Why the model matters
Market history should survive source churn.
Portals change URLs, identifiers, layouts, agents, and publishing behavior. A durable model preserves the physical-property hypothesis and each source-specific episode while allowing evidence and confidence to evolve.
01
Identity before aggregation
Unresolved candidates do not silently inflate supply or contaminate comparable sets.
02
Episode before history
A relisted property can begin a new marketing period without erasing its earlier one.
03
Observation before inference
Displayed status, not observed, explicitly removed, and collection failed are kept separate.
04
Evidence before action
Downstream teams can review source, time, precision, and confidence before using the signal.
Interpretation boundary
A listing observation is not an ownership record or transaction record. Displayed asking price is not a completed sale, appraisal, rent roll, occupancy fact, or recommendation.
Quality & decision boundaries
Make absence, change, and collection failure impossible to confuse.
Real-estate pages disappear for many reasons. A useful delivery states what was seen, what changed, what was not seen, and whether the collection attempt itself succeeded.
Observation ledger One listing episode
14 Jul Observed
First observed active · €296,000
22 Jul Changed
Displayed asking price reduced · €286,000
28 Jul Not observed
Listing absent from the approved page object
30 Jul Failed
Collection did not produce a valid observation
“Not observed” does not become sold, rented, withdrawn, or off-market unless the public source explicitly supports that interpretation.
WSA observes
Public listing evidence
Approved public pages, displayed asking terms, attributes, status, content, source identifiers, and collection outcomes.
Contracted processing can add
Structure, resolution & history
Normalized fields, property and episode matching, derived metrics with labels, change history, quality checks, exceptions, and delivery.
Your team decides
Property and regulated actions
Valuation, acquisition, investment, development, lending, insurance, pricing, leasing, housing, screening, and compliance actions.
Operating models
Start with the real-estate workload. Choose the ownership boundary.
Run your own collectors, use web access APIs, receive a contracted property feed, or hand off the agreed data operation. Each model changes who owns extraction, matching, history, quality, and maintenance.
Infrastructure for your collectors
Run your property collectors through proxy infrastructure.
WebScrapingAPI operates the contracted proxy-network features. Your team owns source selection, collectors, rendering, extraction, geocoding, property resolution, listing history, quality, maintenance, delivery, and decisions.
Proxy infrastructure ownership for real-estate data
Lifecycle responsibility Owner
Sources, geographies, property types & rules A sua equipa
Proxy routing, rotation & contracted location options WSA
Collectors, extraction, schema & geocoding A sua equipa
Property matching, history, quality, maintenance & delivery A sua equipa
Valuation, investment, housing & regulated decisions A sua equipa
On-demand public page access
Retrieve eligible property pages through a maintained access layer.
WebScrapingAPI maintains documented request handling, routing, retries, supported rendering, and the response mode selected. Your team owns the target list, extraction rules where applicable, property resolution, history, quality, and downstream interpretation.
API ownership for real-estate data
Lifecycle responsibility Owner
Sources, URLs, fields & request timing A sua equipa
API access, routing, retries & supported rendering WSA
Extraction & schema returned By endpoint
Geocoding, property matching, history & downstream quality A sua equipa
Valuation, investment, housing & regulated decisions A sua equipa
Recurring structured delivery
Receive agreed property and listing observations on schedule.
WebScrapingAPI operates contracted collection, extraction, normalization, schedule, quality monitoring, source-change maintenance, and delivery. Geocoding, property resolution, episode logic, derived metrics, and history are included only when specified.
Scheduled real-estate feed ownership
Lifecycle responsibility Owner
Source set, fields, match rules & acceptance criteria Your team + WSA
Access, collection, supported rendering & extraction WSA when contracted
Normalization, geocoding, property and episode resolution WSA when contracted
Scheduling, quality, maintenance, history & delivery WSA
Valuation, investment, housing & regulated decisions A sua equipa
Operated property-data program
Hand off the contracted collection and delivery operation.
Bring the market question, sources, geographies, asset types, schema, match rules, cadence, governance requirements, and destination. WebScrapingAPI designs and operates the agreed workflow with your team.
Managed real-estate data program ownership
Lifecycle responsibility Owner
Business question, internal truth, rules & exclusions A sua equipa
Source onboarding, access, collection & extraction WSA when contracted
Normalization, resolution, history & evidence WSA when contracted
Scheduling, quality, maintenance, exceptions & delivery WSA
Valuation, investment, housing & regulated decisions A sua equipa
Representative real-estate pilot
Validate the listing lifecycle on the cases that usually break it.
Start with one geography and a representative property mix. Include active, reduced, reposted, duplicated, explicitly removed, not-observed, ambiguous, and failed states before scaling.
- 01 · Frame
Define the market question
Choose geographies, property types, sources, page objects, fields, match rules, cadence, history window, and destination.
- 02 · Sample
Collect the difficult cases
Include normal listings, duplicates, reposts, price changes, mixed units, approximate locations, removals, missing fields, and failures.
- 03 · Validate
Agree the property contract
Review identity thresholds, episode rules, source precision, derived fields, evidence, state semantics, and acceptance criteria.
- 04 · Operate
Launch the right handoff
Assign ownership, connect delivery, monitor source and match quality, retain lineage, and preserve downstream controls.
A pilot validates source feasibility, record semantics, entity resolution, and quality controls—not asset value, ownership, transaction outcome, or the correct business action.
Evaluation questions
What property-data teams should confirm before collection.
Coverage, fields, identity, lifecycle states, address precision, history, maintenance, privacy, operating ownership, and delivery answered directly.
Which real-estate sources and property types can be covered?
Eligible public sources can include residential sale and rental portals, commercial and land marketplaces, auctions, classifieds, and public builder, developer, brokerage, or property-manager pages. Exact sources, property types, geographies, fields, and cadence are validated before production.
Which listing and property fields can be delivered?
Depending on the public source, fields can include normalized address, property type, size, rooms, amenities, displayed asking price or rent, fees, listing status, agent or office business details, media, source URL, first and last observed time, and quality state.
How are duplicate listings matched to the same property?
Exact source identifiers lead. Cross-source candidates can then use normalized address and unit, coordinates, property type, size, room count, text, media, and other public cues. Uncertain matches remain candidate or needs-review rather than being forced.
How are reposted, removed, or missing listings handled?
The record separates the property from each source-specific listing episode and its observations. A repost can begin a new episode for the same property. Not observed, explicitly removed, source status changed, and collection failed remain distinct states.
Can asking-price and listing-status history be delivered?
Yes, forward history can be built from recurring observations, retaining displayed asking terms, status, source, and observation time. Historical backfill depends on a separately validated source and scope.
How often can real-estate records refresh?
Self-service access returns results when called. Scheduled feeds and managed programs use an agreed source-specific cadence based on decision latency, source behavior, volume, and quality requirements.
Are exact addresses and coordinates available for every listing?
No. Some sources expose exact addresses, while others show a street, neighborhood, approximate point, or map area. The record preserves the source's precision and labels normalized or enriched geography separately.
Can agent, owner, tenant, or occupancy information be collected?
Public agent and office business details can be considered when relevant. Private accounts, resident dossiers, tenant or owner profiling, and inferred occupancy are not standard scope. Applicable privacy, purpose, retention, and jurisdiction requirements must be reviewed.
Who maintains collection when a real-estate source changes?
Proxy customers maintain their collectors and parsers. WebScrapingAPI maintains documented endpoint internals and maintains contracted collection, extraction, quality monitoring, source-change work, and delivery for scheduled and managed programs.
How should we pilot and receive the data?
Start with a representative geography, property mix, source set, fields, match rules, cadence, and delivery destination. Validate active, reduced, reposted, duplicate, removed, not-observed, ambiguous, and failed states before choosing API access, a scheduled feed, or a managed program.
Related paths
Continue with the closest property data path.
Build a traceable property-data foundation
Validate property, listing episode, observation, and evidence rules for one market.
Share the portals, property types, geography, fields, cadence, match rules, and destination. We’ll map supportable coverage and produce representative property, episode, observation, and evidence records.