Proptech platforms use the full property record: parcel identity and coordinates, parcel geometry, building characteristics, owner of record, recorded sales and transfers, assessed values and taxes, and an automated valuation with the comparable sales behind it. It originates with county assessor, recorder, and GIS offices, and platforms either collect it county by county or license it from a provider that normalizes roughly 3,000 county formats into one schema and delivers it by API, bulk transfer, or MCP.
Almost every property product starts with the same record. A search product needs to resolve an address to a parcel and return what is known about it. A map needs the polygon and the coordinates. An analytics tool needs sales history, assessed values, and characteristics across a whole market. An AI assistant needs all of it as structured facts it can cite instead of guess at. None of that data is secret, but it is scattered across roughly 3,000 counties in different layouts on different schedules, which is why most teams license it rather than collect it. The questions worth asking a provider are whether the schema is the same in every county, whether the free tier is the real API, how the price scales as usage grows, and whether an agent can use it through MCP or a CLI as easily as an app can through REST.
Four groups cover most product features. Identity and location make everything joinable: parcel ID, normalized address, coordinates, parcel geometry, and census tract. Characteristics are what a listing or a detail page shows: building and living area, bedrooms and bathrooms, year built, stories, construction and roof, and features such as pool and garage. Sales, tax, and valuation carry the numbers: recorded transfer dates and prices, assessed and taxable values, and the modelValue estimate with a comparables endpoint behind it. Ownership and transfers complete the record with the owner of record and the document trail of each recorded sale.
The same record serves every feature. Search reads identity and characteristics. Maps read geometry. Enrichment appends any of it to records you already hold. Analytics reads the whole thing in bulk. An assistant reads whichever part the question needs, through MCP or a CLI rather than a form.
Nearly all of it is public record. County assessors publish characteristics, assessed values, and tax rolls. County recorders file deeds and transfers, which is where owner of record and sale history come from. GIS departments publish parcel boundaries and coordinates. The values that are not on file, such as an automated valuation, are modeled from those records and from recorded sales.
The difficulty is scale. Each county chooses its own field names, formats, identifiers, and publication cadence, so a platform covering more than a few markets ends up maintaining a parser per county. A provider like Realie collects at the source with AI agents, normalizes the counties into one schema keyed by parcel, refreshes it on a rolling, per-county cycle as counties publish, so vintage varies by county, and delivers it through an API for per-address lookups, bulk transfers for whole-market work, or an MCP server for AI agents.
Property data describes a parcel, not a person. It is not a credit report, and Realie is not a consumer reporting agency. Realie's Terms of Use prohibit using the data as a factor in establishing an individual's eligibility for credit, insurance, employment, or housing, or for any other FCRA-regulated purpose, and Realie does not market owner lookups by name.
Product workflows sit inside that boundary because they start from an address, a parcel, or an area: the search a user typed, the records a platform already holds, or the market an analysis covers. The data describes the property, and the product decides what to show. Starting from the address is both the compliant pattern and the one that produces the cleanest data.