A property search on Zillow,
as rows with coordinates.

Two things about this export
will bite you quietly.

The columns are straightforward. Two of their behaviours are not, and both are the kind that produce a wrong answer rather than an error.

The first is that home_type is always empty. It sits in the header row and carries nothing on any row we hold. What makes this worth a paragraph rather than a footnote is that the information is not missing - it is in the wrong column. status comes back as House for sale, Townhouse for sale, Condo for sale, so the property type is right there, glued to the listing state. If you need type as a field, parse it out of status; do not wait for home_type to fill.

The second is that this export mixes two kinds of row, and url is what tells them apart. A /homedetails/ row is an individual property: zpid is a numeric Zillow id, status is a listing state, and price, beds, baths, square footage and zestimate populate. A /apartments/ row is a whole rental community, and all three of those change at once - zpid holds a latitude–longitude pair instead of an id, status holds the community's name instead of a state, and price, beds, baths, sqft and zestimate are all empty. We checked that those three symptoms land on exactly the same rows, and they do. Split on url before you join on zpid or filter on status, or you will be mixing buildings into a table of homes without noticing.

Beyond those two, the formatting is predictable. price, zestimate and sqft are bare digit strings - 340000, not $340,000 - so they cast cleanly but carry no currency or units. beds and baths are single digits in what we hold, with no half-baths, though that may be a property of this sample rather than a guarantee. latitude and longitude populate everywhere, which is what saves the apartment rows: even when the id is unusable, the row still maps. Everything is a string except position, which is JSON-only.

query

The search you submitted, repeated on every row it produced - a place name like Jacksonville, FL, or the Zillow search URL you pasted.

address

The property's address, as one line. On a /homedetails/ row it carries a postcode; on an /apartments/ row it is the community's street address and generally does not.

price

The listed price, as a bare digit string - 340000, with no currency symbol and no thousands separator.

beds

Bedroom count, as a string. Single digits in our runs, with no half-values. Empty on /apartments/ rows.

baths

Bathroom count, same shape and same caveat. We have not seen a half-bath, but that may be this sample rather than a rule - do not assume the column is always an integer.

sqft

Floor area, again a bare digit string with no unit attached. Empty on /apartments/ rows.

home_type

See the note below.

status

Two different things live in this column. On a /homedetails/ row it is a listing state with the type attached - House for sale, Townhouse for sale, Condo for sale, Sold, Active. On an /apartments/ row it is the name of the rental community instead. Check url before you filter on this.

zestimate

Zillow's own valuation estimate, in the same bare-digit format as price. Sometimes absent on property rows and always absent on /apartments/ rows, so treat it as optional.

latitude

The property's latitude, as a string. Populates on every row we hold, including the apartment rows.

longitude

The longitude, likewise. With latitude this is what lets the file go straight onto a map - and it is the one geographic key that works on both kinds of row.

zpid

Not always an id. On a /homedetails/ row this is Zillow's numeric place id and makes a good stable key - though not a fixed-width one. On an /apartments/ row it holds a latitude–longitude pair instead, like 30.195362--81.72241. Size any column for it generously, and do not join on it blind.

url

The listing on Zillow - and the column that tells the two row types apart. /homedetails/ means an individual property; /apartments/ means a rental community. Split on this first and the rest of the file behaves.

image

A photo for the listing, on Zillow's image host. Populates on every row we hold.

position

1-based rank within the query, in the order Zillow returned the listing. JSON only - the CSV and XLSX exports stop at fourteen columns.

Two things to know before you build on this. First, home_type never fills - but the type is not lost, it is inside status (House for sale, Condo for sale), so parse it out of there. Second, the file holds two kinds of row and url is the discriminator: /homedetails/ rows are individual properties with a numeric zpid, a listing state in status and the price fields populated, while /apartments/ rows are whole rental communities where zpid is a latitude–longitude pair, status is the community's name, and price, beds, baths, sqft and zestimate are all empty. Those three symptoms occur on exactly the same rows. Beyond that: prices and areas are bare digit strings with no symbols or separators, latitude and longitude populate on every row so the file always maps, and position exists only in the JSON - so a CSV or XLSX export has fourteen columns rather than fifteen.

The properties here,
the people next door.

This one returns listings. Our other three Zillow services all take an agent profile URL instead - and the fourth link is the same question on a different market.

Things people
ask before signing up.

The questions we hear most. Anything else? Talk to us - humans, not bots, write the answers.