01 · Candidate assetPilot first
Property
The possible stable asset described by one or more public listings and matched only through agreed evidence.
- Normalized address & coordinates
- Property type & attributes
- Canonical key and match state
Property listings data
Track the listing episode. Understand the property history.
Turn eligible public property pages into source-linked records that keep the asset, advertisement, asking terms, agent, displayed status, media, and observation history separate. Begin with a representative pilot; scale only after the contract holds.
Property-listing model
One page can contain several different truths.
A listing is not the property itself. Keep the candidate asset separate from each advertisement, asking term, displayed status, agent relationship, media item, and observation.
02 · Source episodePilot first
Listing episode
A source advertisement with its own identifier, URL, dates, agent or broker, media, and observed status.
- Source listing ID & URL
- Agent or broker
- First seen & last seen
03 · Time-bound observationPilot first
Asking terms & availability
Displayed price or rent, currency, period, incentives, availability, and status captured at an observation time.
- Asking value & terms
- Displayed status
- Price and status history
Interpretation boundaryNot assumed
An advertisement is evidence, not a transaction.
A displayed asking price is not a valuation or sale price. A listing status is not proof of occupancy, ownership, sale, lease, or inventory.
Coverage states
Treat every property source as a page contract.
Coverage depends on the portal, market, page family, discovery input, visible fields, geography, and reuse conditions—not on a generic real-estate label.
Access or source familyEingabeOutput boundaryStaat
Record contract
Make the listing episode inspectable.
Keep source values, normalized fields, asset identity, observation time, and collection state separate enough to audit each change.
Stable asset cues
- property_id
- Canonical key only when property matching is included.
- address
- Source address plus normalized components where scoped.
- attributes
- Type, bedrooms, area, floor, amenities, and source-specific facts.
Advertisement identity
- source_listing_id
- Source identifier retained exactly as observed.
- agent_or_broker
- Displayed public representative and office context.
- episode_state
- Observed, changed, removed, relisted, unavailable, or review.
Terms and status
- asking_value
- Displayed price or rent, not an appraisal.
- currency_and_period
- Currency and rental period retained with the value.
- availability_text
- Literal source status plus an optional normalized state.
Traceability and history
- source_url
- Public page associated with this episode.
- observed_at
- Timestamp for this captured observation.
- first_seen / last_seen
- History bounds under the agreed recurring collection.
{
"property": {
"property_id": "candidate_prop_18",
"type": "apartment",
"bedrooms": 2,
"area_sqm": 78
},
"listing": {
"source_listing_id": "demo_74",
"episode_state": "observed",
"asking_value": 235000,
"currency": "EUR",
"availability_text": "Available"
},
"match_state": "candidate",
"source_url": "https://property.example/listing/demo-74",
"observed_at": "YYYY-MM-DDThh:mm:ssZ"
}Read source terms literally.
Displayed availability is not proof of an open transaction, and asking price is not market value.
Identity and episodes
Preserve every advertisement before resolving the asset.
Address and attribute normalization can support a relationship. It should not erase source listing IDs, episode boundaries, conflicts, or uncertainty.
- 01
Source episode
listing ID + URL
One advertisement on one source. - 02
Candidate cues
Address + geo + attributes
Unit, floor, area, type, and media can support review. - 03
Relationship state
Exact · candidate · ambiguous
Unmatched episodes remain usable. - 04
Property key
Canonical when contracted
Never assumed from a similar title alone.
Freshness and history
A timeline needs observations—not inferred transactions.
Record when the page was requested, when its fields were observed, when the record was delivered, and when a value first or last appeared.
- Requestedrequested_at
The source, URL or search, geography, filters, and locale entered collection.
- Observedobserved_at
The listing exposed the captured asking terms and status.
- Delivereddelivered_at
The record entered the agreed output path.
- Changedfirst_seen / last_seen
A listing episode or field value entered or left tracked history.
Quality and missingness
Absence, removal, and sale are different states.
A defensible property feed makes field absence, collection failure, page removal, source status, duplicate risk, and identity review separately queryable.
Contracted structure present
The public page produced the required listing and provenance fields.
Terms or episode changed
Price, status, agent, media, or page pattern changed under the history rules.
Property match ambiguous
The source episode stays separate until the approved rule resolves it.
No supported observation
Unavailable is not automatically sold, leased, occupied, or removed.
Structural checks
Expected page family, listing key, required fields, data types, and schema version.
Field checks
Currency and period, numeric area, status vocabulary, timestamp, address parts, and image URL shape.
Acceptance boundary
Your team approves source set, required fields, match rules, history semantics, exception thresholds, and downstream use.
Operating model
Choose who operates the property-listing lifecycle.
The right path depends on whether your team wants raw access, owns extraction, or needs a maintained record and history contract.
Maximum infrastructure control
Build your own property collector and history.
Use proxy infrastructure while your team owns discovery, rendering, parsing, property matching, quality rules, source-change response, history, and delivery.
VerantwortungOwner
Object, field, and source briefCustomer
Access and collectionShared
Extraction and source schemaCustomer
Identity, quality, maintenance, and deliveryCustomer
Storage, interpretation, and decisionsCustomer
Property applications
Use one governed history across different analyses.
Each workflow can reuse the source-linked record while retaining responsibility for valuation, legal interpretation, ranking, and decisions.
Listing and price monitoring
Track displayed asking terms, status, and page changes across submitted or discovered listings.
Listing episode · asking observation · timeMarket supply research
Measure observed listing composition within a defined source and geographic universe.
Property attributes · geography · provenanceComparable discovery
Surface candidate comparables for analyst review without presenting an automated appraisal.
Attributes · location · asking termsBrokerage intelligence
Study public agent, broker, office, and listing relationships as displayed by target sources.
Listing · broker · public contactsPortfolio watchlists
Monitor public listing signals related to submitted addresses or candidate assets.
Property candidate · episodes · change statesModel inputs
Provide traceable public observations to customer-owned research and valuation models.
Source values · features · timestampsRepresentative pilot
Prove the schema on the pages that can break it.
Include standard listings, rentals and sales if relevant, missing fields, price changes, removed pages, duplicate advertisements, relists, address ambiguity, and source-specific media.
- 01
Define
Share target sources, geography, discovery path, objects, fields, cadence, and downstream use.
- 02
Sample
Select ordinary and edge-case listings with changes, removals, duplicates, missingness, and ambiguity.
- 03
Inspect
Review source values, episode identity, candidate property matches, timestamps, and states.
- 04
Accept
Approve schema, matching, history semantics, thresholds, cadence, and operating ownership.
Evaluation FAQ
Resolve the property-listing contract before scale.
Ten practical answers for data, research, and operations teams evaluating public listing data.
What property listing data can WebScrapingAPI provide?
A scoped delivery can include property attributes, source listing identifiers, listing episode dates, displayed asking price or rent, currency and period, availability or status text, agent or broker details, public media references, source URL, observation time, and price or status history. Actual fields depend on the selected public sources and representative pages.
Is there a documented real-estate endpoint?
WebScrapingAPI does not currently present a dedicated structured real-estate endpoint. Eligible public listing pages can be accessed through the generic Scraper API or Browser API, while structured schemas, recurring collection, cross-source matching, and maintained delivery are pilot-first or custom managed scopes.
How are properties and listings kept separate?
The model treats a property as a candidate stable asset and each public advertisement as a listing episode with its own source listing ID, agent, asking terms, status, media, and observed history. A listing is not the property itself, and the same property may have multiple or repeated listing episodes.
Can listings be matched across portals?
A scheduled or managed pilot can test matching rules using source IDs, normalized address, coordinates, property type, unit or floor, bedrooms, area, and other agreed cues. Exact, candidate, ambiguous, unmatched, and source-only states remain explicit; source records are not silently merged.
Can asking-price and availability history be delivered?
Recurring collection can retain first_seen, last_seen, observed_at, asking terms, displayed status, and change events for submitted or discovered listings under the agreed cadence. A displayed asking price is not a valuation, and a displayed availability state is not a transaction or occupancy guarantee.
How fresh can property listing data be?
Freshness is confirmed per source, page family, geography, volume, and required field. Request-time access returns an observation when processed; scheduled and managed programs use an agreed collection window and make late, unavailable, failed, and source-absent states visible.
How are removed, relisted, or duplicate listings handled?
The record contract can distinguish a source-reported status, page removal, temporary unavailability, collection failure, suspected duplicate, relisted episode, and ambiguous property match. A disappeared page is not automatically labelled sold, leased, or unavailable unless the source provides that evidence.
Can photos and floor plans be included?
Public media URLs, captions, order, and related metadata can be evaluated as part of a listing record. Delivery of media files, reuse rights, duplicate-image analysis, and retention are separate scope decisions; public visibility does not transfer media rights.
Who maintains a recurring property feed when sources change?
Proxy customers maintain their own collectors and parsers. For a scheduled or managed property program, WebScrapingAPI can own contracted collection, extraction, schema maintenance, quality monitoring, source-change response, history, and delivery, while the customer owns downstream storage, interpretation, and decisions.
What property sources and conclusions are outside standard scope?
Private or credentialed MLS systems, gated owner or tenant data, private transaction records, and appraisal guarantees are not standard scope. Customers remain responsible for lawful use, licensing, retention, access controls, valuation methods, and decisions made with public listing observations.
Property listings data
Start with a representative property record set.
Bring the public sources, geography, listing objects, required fields, cadence, and intended decision. We will use the pilot to prove the contract.