Zillow property data explained: fields, filters and endpoints

Property integrations usually fail at a boundary, not in the HTTP client. A search parameter gets mistaken for a returned field, a filter from the sale endpoint is sent to rentals, or an address is used as a database key and changes formatting on the next run. The safest starting point is the contract that is actually exposed by the LetsScrape Zillow API today.

This guide documents the current LetsScrape offer on RapidAPI. LetsScrape is not affiliated with, endorsed by or sponsored by Zillow.

The active API surface contains seven GET endpoints. The listing workflow is deliberately split into sale, rent and sold routes. There is no current generic /v1/search route, and the paths do not use the older /zillow/v1 prefix.

Endpoint decision table

Search endpoints return collections suitable for discovery, feeds and snapshots. The property endpoint expands one known record. Market trends are a third data shape: they describe an area rather than a property. Keep these models separate in your application even if they share a location label.

Request parameters versus response fields

Names in a query string control the request. They are not guaranteed to appear in each returned listing. For example, price_max is a request filter; price is a response field. Likewise, location_or_rid chooses an area, while address, latitude and longitude describe an individual result.

Filters that exist today

The three listing routes share the basic range filters but diverge after that. Comma-separated enum values should come from the current endpoint options. Do not send a rental amenity to the sale route simply because another scraper supports it.

Sort values also differ. Sale and sold declare relevant, price_asc, price_desc, newest, beds, baths, size and lot. Rent declares verified_score, payment_asc, payment_desc, recommended, newest, beds, baths, size and lot.

Pagination and location input

page is a required numeric parameter on sale, rent and sold searches, with a documented default value of 1. Increment it explicitly and stop when the returned listing collection is empty or when a page adds no new zpid values. Do not invent a total-page field, cursor or page size unless the response you receive actually contains one.

location_or_rid accepts either a human location such as a city or a region identifier. Autocomplete is useful when a user types partial text: call /v1/autocomplete?query=..., present the suggestions, retain the returned regionId, and send that value to the chosen listing route. This avoids ambiguous place names. A direct url is the alternative when your application already has a Zillow search URL.

Map search behaves differently. Supply north, south, east and west as numeric latitude/longitude bounds plus the required type. The current coordinate endpoint does not declare pagination or the listing filters above, so a map client should not assume feature parity.

Response field groups

Successful calls use a top-level status and data wrapper. The listing collection inside data can be source-dependent, so find the array of objects containing zpid rather than hard-coding an undocumented container. The current public response contract documents these listing fields:

The property-detail route is for richer, nested data after search. The offer describes details such as price and address, physical attributes, estimates, tax and price history, HOA information, schools, photos, agent data and description. Those groups depend on what the source page exposes. Do not manufacture missing keys or promise that a rental, land parcel and sold home share one complete detail schema.

The market endpoint returns area-level indicators including the Zillow Home Value Index (ZHVI) and Zillow Observed Rent Index (ZORI). Keep those series out of your property table: a market observation is keyed by its location and observation period, not by zpid.

Compact listing sample

This valid JSON shows one documented listing object. The placeholder collection name is intentional because the surrounding collection is source-dependent.

{
  "status": 200,
  "data": {
    "<listing collection>": [{
      "zpid": "19977945",
      "address": "Example address, Miami, FL",
      "price": 450000,
      "price_": "$450,000",
      "beds": 3,
      "baths": 2,
      "area": 1450,
      "statusType": "FOR_SALE",
      "daysOnZillow": 4,
      "latitude": 25.7617,
      "longitude": -80.1918,
      "imgSrc": "https://example.invalid/photo.jpg",
      "detailUrl": "https://www.zillow.com/homedetails/19977945_zpid/"
    }]
  }
}

zpid is the identity; price is the calculation value; price_ is presentation; coordinates are numbers; and media is nullable. Example hostnames and addresses are illustrative, while field casing follows the verified response contract.

Normalization pattern

from datetime import datetime, timezone
from decimal import Decimal, InvalidOperation

def decimal_or_none(value):
    if value is None or isinstance(value, bool):
        return None
    try:
        number = Decimal(str(value))
        return number if number.is_finite() else None
    except (InvalidOperation, ValueError):
        return None

def normalize_listing(row):
    return {
        "zpid": str(row["zpid"]),
        "price": decimal_or_none(row.get("price")),
        "area_sqft": decimal_or_none(row.get("area")),
        "lot_value": decimal_or_none(row.get("lotAreaValue")),
        "lot_unit": row.get("lotAreaUnit"),
        "latitude": decimal_or_none(row.get("latitude")),
        "longitude": decimal_or_none(row.get("longitude")),
        "observed_at_utc": datetime.now(timezone.utc).isoformat(),
    }

Common integration mistakes

• Using an old route. The active routes start with /v1 and split sale, rent and sold searches. Do not call a generic /zillow/v1/search.
• Sending type to a regional search. Choose /sale, /rent or /sold; type belongs to /v1/search/coords.
• Assuming every endpoint shares filters. The coordinate route has only five declared inputs, while rentals and sales have different filter sets and sort enums.
• Confusing numeric and display values. Calculate with price, not price_.
• Treating estimates as guaranteed prices. zestimate and rentZestimate are optional estimates and may be absent.
• Stopping after one page. Increment page for the three regional listing routes and deduplicate by zpid.
• Assuming all HTTP failures use the success wrapper. Handle 400, 429, 500 and 504 responses before reading data; gateway authentication errors may have a different JSON body.
• Overwriting null with zero. Missing beds, area, estimates or coordinates mean unknown/not supplied, not necessarily zero.

Choosing a stable internal identifier

Use zpid as the external property key and store it as text. It survives price, status, photo and address-format changes better than a URL or a concatenated address. A practical unique constraint is (source, zpid), where source is your own constant such as zillow. Keep regionId separate: it identifies a search region, not a property.

For history, do not update one row and discard the old value. Store an observation keyed by your internal property ID and observed_at_utc, then compare price and status between snapshots. This preserves provenance while letting the current-property table remain small.