Zillow listing data feed
- Coverage
- Your address or ZIP list
- Cadence
- Weekly, daily on active
- Typical volume
- ~10k records
- Difficulty
- Very high
- Price
- $500 / mo
What's in it
Market-listing context for properties you already track, scoped to the addresses, ZIPs, or areas you name:
- Listing status - active, pending, contingent, sold, off-market, with transition dates
- Pricing - current list price, prior list price, and the full price-change history with dates
- Days on market - cumulative and current-listing, which are different numbers and frequently confused
- Listing detail - beds, baths, square footage, lot size, year built as displayed on the listing
- Valuation estimate - the published automated estimate where present, carried as an estimate and never as an assessed value
Keyed to the same normalized address and parcel identifier used across the property stack, so listing activity lines up against the county record for the same property rather than sitting in a separate table you have to join yourself.
Delivery
Weekly refresh, with a daily option on an active-listing subset. Lands in S3, a webhook, or your database. This feed is deliberately scoped and low-volume: it is built as enrichment on a property list you already hold, not as a market-wide listings database.
Why this one is hard
This is a consumer platform, not a public record, and that changes the whole shape of the problem. Everything else in the property stack is published by a government office under an open-records statute. This is not, and the honest framing matters more than the engineering: you are buying scoped enrichment on a list you already have, delivered at low volume, and it is priced accordingly.
The anti-bot posture is the most aggressive in the property stack. Consumer real estate sites run commercial bot-management products with behavioural fingerprinting, and the naive approaches stop working within days. Sustaining it means low request rates, heavy caching, and accepting lower coverage rather than pushing through, which is exactly the opposite of how the county sources are run.
Price history is presented, not stored. What a listing page shows as history is a rendered view that can change retroactively when a listing is relisted, withdrawn, or re-entered under a new identifier. Treating it as an immutable log produces silent errors. The workable approach is to snapshot what was displayed, timestamp it, and keep your own history rather than trusting theirs.
The identifier is unstable. A property that goes off-market and relists can come back under a different listing id, which breaks naive keying and shows up as a phantom new listing. Resolution has to run on the address and parcel, not the site's own id.
If what you actually need is comprehensive market-listing data at scale, the correct answer is a licensed MLS or IDX feed through a broker relationship. That is what the industry runs on, it costs money, and it comes with redistribution rights. This feed is not a substitute for it and is not sold as one.
Build versus buy
Build it yourself if you need a few hundred addresses checked occasionally and you are comfortable owning the terms question. At that scale it is a small job.
Buy it when it needs to run on a schedule next to your county data, because the recurring cost here is not the initial scraper. It is keeping a scoped, low-rate, well-cached pipeline alive against a defence that updates continuously, and doing it without letting volume creep up. That discipline is most of what $500/mo buys.
Buy a licensed IDX feed instead if you need whole-market coverage, real-time updates, or contractual certainty about redistribution. I will tell you that on the feasibility check rather than sell you the wrong thing.
Related
This feed is the market-context layer of the Property & Public Record Stack ($5,500/mo). The record layer underneath it is county assessor and recorder data, Secretary of State filings, and state court records, all of which are public record and carry none of the constraints above.