Zillow Scraping: Listing IDs, Prices and Status History

Zillow scraping raises a data-model question before a page-collection question: what exactly is the record being compared? A physical property, a source listing, an offer and an observation are different entities. Overwriting one row by its current URL can hide relistings, confuse rental and sale prices, and convert a failed refresh into a false market event. BotBrowser provides declared browser and geographic inputs for authorized observations; it does not provide property data or grant access to a portal. Use an approved source, retain only permitted history, and make every change refer to a defined listing occurrence.

TL;DR

• A source listing key, a property reference and a URL have different meanings. Establish their actual semantics instead of assuming one permanent global key.
• Compare prices only after currency, transaction type and price basis match. Equal numbers can represent different offers.
• Preserve source status and observation outcome separately. A missing card, timeout or parser failure does not establish a sale or withdrawal.
• Treat a permitted refresh as a typed comparison against an accepted observation, not an unconditional overwrite of the latest row.
• An official API or industry standard does not itself authorize access or indefinite retention. Use the applicable source agreement and stop where permission is unavailable.

Contents

• Establish authorized listing access
• Separate property, listing and observation identity
• Compare prices with their transaction meaning
• Retain status evidence without inventing market events
• Apply a typed comparison to each refresh
• Keep browser context and storage within their roles
• Practical conclusion

Establish authorized listing access

The Zillow Group MLS Listings documentation describes Bridge Listing Output as access to MLS listing data, normalized to the RESO Data Dictionary. It also states that data access is at the discretion of individual MLS partners in the US and Canada and that the platform is currently invite only. A documented integration is therefore a source option with conditions, not a public dataset entitlement. Documentation access does not establish authenticated access to any listing dataset.

The developer catalog lists offerings for public users and partners across different real-estate functions. That catalog does not establish that a particular application can obtain every property field or reuse it for every purpose. Identify the actual provider, available dataset, permitted fields and intended use before building a collector. The applicable agreement must also answer retention and redistribution questions. Technical availability and a supported integration remain weaker than permission for the specific application.

RFC 9309 explicitly says that robots rules are not access authorization. Public page visibility does not settle the agreement either. A source that prohibits the intended collection should not receive a browser workaround; use an approved alternative or return the unsupported requirement. The current portal terms must be reviewed where applicable. No uninspected term is treated as verified, and no source permission is inferred from a successful documentation request.

The shared observation pipeline separates collection from later analysis. Real-estate data adds source-specific permission and entity semantics at that boundary. An approved feed, a supplied redacted fixture and a separately authorized interface observation are different source choices. Preserve which choice supplies the record. A common downstream table does not make their rights, completeness or field meanings interchangeable.

Separate property, listing and observation identity

RealEstateListing describes a listing of one or more real-estate offers, with the overall listing represented on a web page. It is not simply another name for the physical property. The vocabulary is in schema.org's new area and does not establish that Zillow uses particular markup or identifiers. Use it to distinguish concepts, not to infer a portal-specific extraction contract. Actual source keys must come from the approved source and its documented meaning.

Model component	Evidence or reference to preserve	Boundary
Source namespace	Actual provider and dataset	Similar keys from different sources need not identify the same record
Listing occurrence	Provider-defined listing reference when available	A relisting is not automatically continuity of the previous offer
Physical property	Separately supported property reference	A listing key or shared address is not universal property identity
Offer meaning	Sale or rental scope and price basis	A purchase price and recurring rent are not comparable amounts
Observation	Source time when supplied, observation time and outcome	Collection time is not publication or transaction time
Reference location	Actual source URL or other supported reference	A URL change is not automatically a new property or listing

The Place vocabulary describes physical-location properties such as address. An address observation can support matching, but it does not prove that two source listings represent one unit, one legal parcel or one offer. Shared buildings and differently formatted addresses make that distinction necessary. Keep a separately resolved property identity optional where evidence is insufficient. Do not erase independent source listing occurrences merely because their visible addresses resemble each other.

The job-posting identity comparison separates a source occurrence from a real-world entity. For property data, an expired offer and a later listing can concern the same physical place while remaining different listing occurrences. The application should preserve that distinction unless the source establishes continuity. A newly observed URL or identifier creates a reconciliation question, not an automatic market event. If a reliable key is unavailable, record provisional identity and its limitation.

The RESO Data Dictionary defines consistent real-estate resources, fields and lookup values for interoperability. It is a language for data, not the dataset itself or a license to obtain it. Map actual source fields using the version and semantics supplied by the approved integration. A familiar field label does not guarantee that every provider populates it, updates it at the same time or uses a universally comparable listing key.

Compare prices with their transaction meaning

The Offer vocabulary separates price and currency and describes the transaction through the offered item and business function. Those concepts prevent a bare numeric column from carrying too much meaning. An amount needs its currency, sale or rental scope, and any recurring period or unit basis actually supplied. This is a field interpretation rule, not a claim about a current Zillow response. Unknown context must remain unknown rather than being inferred from browser language or a currency symbol alone.

A constructed comparison makes the distinction explicit: USD 2,500 per month and USD 500,000 asking price do not describe a price increase between comparable observations. They describe different transaction meanings. Likewise, two equal amounts in different currencies are not an unchanged price. Establish the same intended listing occurrence and comparable offer basis before calculating a difference. If the source changed the scope of the offer, preserve that scope change separately from any numeric calculation.

Schema.org's price guidance recommends a separate priceCurrency value rather than ambiguous currency symbols. The application can apply a typed representation to permitted source values without inventing the absent currency or recurring period. Keep both the source meaning and the normalization rule available within allowed retention. Locale-sensitive formatting is a parsing concern; a separator change does not by itself establish a market movement. A formatted string and a comparable amount are different representations.

The RealEstateListing publication field gives datePosted the meaning of an online listing's publication date. That is distinct from the collector's observation time and from the date of a price revision. First observing an amount today does not prove it changed today. If a source supplies its own effective timestamp, retain that timestamp's meaning separately. Historical analysis should not silently replace missing event time with processing time and then call the result a transaction timeline.

Retain status evidence without inventing market events

The RESO dictionary organizes fields and lookup values, but an application must still use the actual supported source mapping. Preserve the raw source status and the interpretation rule rather than assuming every feed shares a universal transition graph. A source reporting an off-market state does not by itself establish a completed sale. A collector failing to find a card establishes less: absence in that particular observation, not the property's legal or commercial outcome.

Constructed event	Permitted observation	Accepted interpretation
First accepted record	Listing L, USD 500,000 asking price, source status active	Baseline observation, not a newly completed transaction
Later comparable record	Same listing L, USD 490,000 asking price	Source-observed price revision with observation time
Refresh fails	No accepted source record	Collection incident; no price deletion or status change
Card missing from one list	No observation of L in that list	List absence; sale and withdrawal remain unestablished

The table is an application fixture, not a measured sequence from Zillow or an MLS. The second row supports a comparable asking-price observation, not a final sale price or evidence of negotiation. The failure row should leave the earlier accepted value intact as historical evidence, subject to the agreement. It must not present that older value as a successful fresh observation. A retained accepted value and the latest collection outcome answer different questions.

RealEstateListing and Offer semantics keep a listing and its offers distinct from a completed real-world transaction. Require explicit, appropriately scoped source evidence for any sold or withdrawn classification. If the approved source does not establish that state, use unknown or the narrower raw status. Repeated missing observations may motivate investigation, but repetition alone does not make an unsupported inference a source fact. Do not turn collection failures into market statistics.

Apply a typed comparison to each refresh

A permitted refresh should first establish the intended source and listing occurrence, then validate the required representation and fields. Only accepted, comparable observations should enter field-level comparison. The RESO field model can inform a source mapping, but it does not select the application's acceptance policy. State whether incomplete records are rejected or retained with unknown fields. Neither policy should silently reinterpret a failed observation as an empty replacement record.

The ordered comparison rule is concrete: identify the source occurrence; classify collection outcome; interpret supported fields; compare like-typed values; record supported differences; retain unresolved questions separately. If the occurrence identity is uncertain, postpone the comparison instead of manufacturing a revision. If currency or transaction basis differs, classify the difference in meaning before any arithmetic. If only a URL changes, inspect the source reference semantics rather than creating a new property by default.

The job-listing observation model preserves repeated observations under a source-scoped key. A property listing needs that history as well as typed price and status handling. An unchanged accepted record is another observation, not a duplicate real-world transaction. An unaccepted refresh is an incident, not evidence that every field vanished. Deduplication of storage operations should not erase the distinction between an entity, a source record and evidence gathered at different times.

For an owned fixture test, replay the four table events and check their interpretations. The expected result is one comparable asking-price revision, one collection incident and one unresolved absence after the baseline. No sale, new property or price deletion should be invented. That acceptance exercise tests the application model without collecting protected portal content. Keep the fixture's synthetic nature explicit; passing it does not establish a particular provider's current update cadence or field completeness.

Keep browser context and storage within their roles

The BotBrowser GeoIP documentation describes geographic lookup with profile prerequisites and proxy routing. Those are browser-environment inputs for an authorized observation. They do not establish the location of a property, the currency of an offer or the completeness of a geographic search. Verify the actual permitted source state independently. A configured region must not become a substitute for a missing listing field.

The profile configuration guide describes profile-backed browser settings. Use the supported configuration and verify actual loading when a runtime observation is performed. Browser configuration alone does not establish a runtime observation of a portal. Stable declared inputs can make a comparison environment more explicit, but they do not grant source access or guarantee identical listing content between observations. Source changes and browser incidents remain different possible explanations.

MDN's IndexedDB reference describes transactional, keyed storage of structured data with same-origin restrictions. Such storage can support a local application fixture or permitted observations, but it does not make the browser an authoritative property-history service. Storage limits and eviction also matter; local persistence is not an indefinite archival guarantee. The choice of a database cannot expand a provider's allowed retention or authorize collecting a missing dataset.

Retain content and operational evidence only under the applicable agreement. If raw history cannot be stored, redesign the diagnostic record within the permitted scope instead of keeping a full response archive under another name. RFC 9309 does not turn robots rules into rights for that archive. Stop where source permission or required evidence is unavailable. Neither a different browser identity nor a database transaction establishes the missing authorization or market fact.

FAQ

Is a property URL a reliable permanent listing key?

Only if the approved source establishes those semantics. A URL, listing occurrence and physical property answer different identity questions. Preserve source references and uncertainty instead of assuming every URL change creates a new property.

Does a missing listing mean the property sold?

No. A missing card, failed refresh or incomplete observation does not establish a completed sale. Preserve the collection outcome and require explicit source evidence for the lifecycle state needed by the application.

Can every price be compared as one number?

No. Currency, sale or rental meaning and recurring period or unit basis must be comparable. Missing context is not permission to infer it from locale or display punctuation.

Does an official API or BotBrowser grant portal data access?

No. The documented MLS option has partner-controlled access and an invitation condition. BotBrowser provides browser inputs, not property content or permission. The actual integration agreement determines access and allowed retention.

Sources

• Zillow Group MLS Listings
• Zillow Group developer catalog
• RESO Data Dictionary
• schema.org RealEstateListing
• schema.org Place
• schema.org Offer
• MDN IndexedDB API
• RFC 9309
• BotBrowser GeoIP database
• BotBrowser profile configuration

Practical conclusion

Build permitted listing history from source-scoped occurrences and accepted observations, not unconditional URL overwrites. Compare prices only with their transaction meaning, preserve raw status and unknown lifecycle states, and keep failed refreshes separate from market changes. Browser inputs and local storage support the application; the approved source and its agreement determine what data is available, what it means and what history may be retained.