ATTOM vs. PropertiesAPI: Public Records or Zillow Listing Data?

A comparison written by one of the two vendors

PropertiesAPI wrote this article and sells one of the services it compares. We describe ATTOM from its own public product page and API documentation, linked below, and we say where ATTOM covers needs that we do not. Product scope and access terms change, so check both vendors' current pages before you commit.

We should also be explicit about a gap: PropertiesAPI does not currently supply ownership records. If your workflow starts with who owns a property, deeds, mortgages or foreclosure research, that alone points you toward a public-records provider such as ATTOM.

Public records and listing pages answer different questions

Public-record data starts from documents that counties and other agencies maintain: assessments, recorded deeds, sales transactions and mortgages. A records provider gathers, standardizes and links them to a property identifier. It answers questions about ownership, transfers, tax values and the recorded history of a parcel.

Listing data starts from how a property is presented for sale or rent. A Zillow page shows the current listing status and asking price, photos, the listing agent and broker, Zillow's estimates when shown, and a source-reported event history. It answers questions about what is on the market and how a specific listing looks today.

The two overlap in places, such as beds, baths, square footage and tax amounts, but even shared fields can differ because they come from different sources at different times. Decide which source is authoritative for each field your product shows.

• How to match data categories to your workflow

What ATTOM offers, from its own pages

ATTOM's property data API documentation lists property characteristics and profiles, owner and mortgage details, assessment and tax values with history, sales history and sales trends, automated valuations including a rental valuation, combined property event views, building permits and school data. Its product page describes a nationwide data warehouse and lookups by address, assessor parcel number, ATTOM ID or coordinates, with JSON or XML responses.

Access starts with a free trial account on its developer platform, which issues an API key. Its product page describes scalable pricing and packaging, with tailored options through its sales team, rather than a published self-serve price list. Confirm current trial terms, licensing and permitted use directly with ATTOM.

ATTOM's product page does not describe Zillow listing data, and its property API documentation centres on records and valuations. If listing status, listing photos or agent details are central to your product, ask ATTOM what it supplies for those before assuming either way.

What PropertiesAPI offers

PropertiesAPI looks up one known property at a time, or a list through the batch endpoint, from a Zillow link, a zpid or a US address. It returns what the public Zillow page shows: listing price and status, Zillow's Zestimate and rent Zestimate when shown, home facts, photo URLs, price history, tax history, schools, parcel number when shown, and the listing agent and broker.

It does not supply owner names, deeds, mortgages or foreclosure filings, does not search for properties, and does not produce valuations of its own. Values are provided as shown on the page at collection time, as-is, and are not licensed or official records. Each response reports when the page was collected.

• Every field in the property response
• Plans and credit rules

Which service fits which task

This table reflects each vendor's public documentation on the date of this article. It describes fit, not quality, and neither column claims accuracy for any estimate.

Combining the two with a parcel handoff

Some workflows need both: listing context from the Zillow page and ownership or transaction history from public records. A practical pattern is to look up the known properties first, then hand off the identifiers a records service can match on. The script below collects the returned address, county, state, ZIP, coordinates and parcel number when the page shows one, plus the page's assessed value so you can compare it with the record later.

It makes no request to any records service. Use the identifiers to query your records provider according to its own documentation, and verify the match before joining. Parcel number formats vary by county, so normalize them with the county in mind and treat a parcel number from a listing page as a lead to check, not as a confirmed key.

Keep both values when they disagree. An assessed value on a page and one in a county record can reflect different tax years. Store the source and tax year with each, and choose which one your product displays.

Rows marked review carry an identity warning and should not be handed off until someone confirms which property the response describes. Rows that failed keep their status so the handoff file still accounts for every input. Joining public records to the wrong parcel is harder to notice later than a gap is now.

• Resolve ambiguous addresses before joining

"""records_handoff.py: look up known properties, then prepare a file for a public-records query.

Reads addresses.txt (one address per line). Writes handoff.csv with the identifiers a
records service can match on. It makes no request to any records service.
"""
import csv
import os
import sys

import requests

API = "https://api.propertiesapi.com/v1/zillow/property"


def lookup(session, address):
    response = session.get(API, params={"address": address}, timeout=(10, 140), allow_redirects=False)
    if response.status_code != 200:
        return {"status": f"http_{response.status_code}"}
    body = response.json()
    data, meta = body["data"], body["meta"]
    dated = [tax for tax in data["taxHistory"] if tax.get("year")]
    latest_tax = max(dated, key=lambda tax: tax["year"], default={})  # order is not guaranteed
    return {
        "status": "review" if meta.get("warning") else "ok",
        "zpid": data["zpid"],
        "returned_address": data["address"],
        "county": data["county"],
        "state": data["state"],
        "zipcode": data["zipcode"],
        "parcel_id": data["parcelId"],              # as shown on the page; may be null
        "latitude": data["latitude"],
        "longitude": data["longitude"],
        "page_assessed_value": data["taxAssessedValue"],
        "page_latest_tax_year": latest_tax.get("year"),
        "fetched_at": meta["fetched_at"],
    }


def main(path="addresses.txt"):
    session = requests.Session()
    session.headers["x-api-key"] = os.environ["PROPERTIESAPI_KEY"]
    columns = ["input", "status", "zpid", "returned_address", "county", "state", "zipcode",
               "parcel_id", "latitude", "longitude", "page_assessed_value",
               "page_latest_tax_year", "fetched_at"]
    with open("handoff.csv", "w", newline="", encoding="utf-8") as out:
        writer = csv.DictWriter(out, fieldnames=columns)
        writer.writeheader()
        for address in filter(None, (line.strip() for line in open(path, encoding="utf-8"))):
            writer.writerow({"input": address, **lookup(session, address)})


if __name__ == "__main__":
    main(*sys.argv[1:])

How to decide

If ownership, transfers, liens or a records-based valuation are central to your product, start with a public-records provider; PropertiesAPI cannot cover that today. If your users bring a Zillow link or an address and want what that listing shows, start with a lookup. If you need both, keep them as two clearly labelled sources and test the join on your own sample before relying on it.

Whatever you choose, test with your own addresses, record what each service returned and when, and read the licensing terms for storage, display and redistribution. A short, documented evaluation is worth more than any comparison table, including this one.

• Make your first PropertiesAPI lookup