The Property Data API Paradox: More Sources, Less Agreement

The industry has largely solved the problem of getting property data. It has not solved the problem of agreeing on it.

A team building a nationwide property product once had to assemble assessor and recorder data, tax records, mortgage and lien information, MLS feeds, permits, parcel geometry, valuations, and the matching pipelines to hold them together. Wholesale providers now package most of that behind a handful of endpoints. That is real progress, and it removes months of undifferentiated work.

It also moves the bottleneck up the stack.

A vendor record is a representation, not the property

Two capable providers can return different values for the same house without either being wrong. They are answering with different construction, and the differences are deliberate.

None of that makes a provider bad. It makes providers non-interchangeable — which is a different and far more manageable problem, provided you model it rather than assume it away.

No vendor identifier is your primary key

Every provider exposes its own property identifiers, and they work well inside that provider’s graph. They are not shared with another vendor, an MLS, or a county assessor.

The moment a vendor identifier becomes your primary key, replacing that vendor turns into a migration rather than a configuration change. Property identity is a hard problem in its own right;⁴ the point here is narrower — whatever you resolve to, it has to be yours.

Model the disagreement instead of deleting it

Four sources describe one house. The MLS reports four bedrooms and 2,480 square feet. A commercial provider reports three and 2,310. The assessor agrees with the provider. A closed permit records an added bedroom and 170 square feet.

The weak pipeline settles this with a precedence rule: the MLS wins. That produces the right answer here and the wrong one the moment the MLS is the stale source.

Not every disagreement is a data-quality problem, either. Two providers can both be correct and still differ because they answered different questions — assessor area against agent-reported area, recorded grantee against mailing owner, assessed value against a modeled valuation. Standard vocabularies narrow this but do not close it: the same standardized concept is legitimately expressed differently across systems.¹² Mapping every provider’s equity field into one enterprise column without carrying its calculation context does not create consistency. It creates the appearance of it.⁵

Route by field, not by vendor

“Which provider is best” is the wrong question. Coverage, freshness, and authority belong to the field, the geography, and the event type — not to the provider as a whole. A source that leads on listing activity may lag badly on ownership transfers.

The policy differs by question: ownership favors authoritative transfer evidence, listing status favors the originating MLS, contact data favors measured reachability, valuation depends on property type and geography. Calling every provider on every request is simply the expensive way to arrive at the same uncertainty.

Routing needs time to work with, which means keeping the dates apart — when a fact became true, when the source observed it, and when you ingested it are three different things, and collapsing them is what makes a “fresh” record quietly wrong.⁶

Measure providers like production dependencies

Most teams monitor a vendor API for uptime and latency. That measures the transport. It says nothing about whether the data got worse.

The last one tends to change procurement conversations, because the cheapest feed per call is frequently the most expensive per resolved answer. The same instrumentation earns its keep operationally: it is what tells you that a provider’s bedroom distribution shifted overnight, that parcel-number completeness dropped in one state, or that contact hit rate has been sliding for a month.

One contract above all of them

Applications should not know which vendor answered. A gateway keeps procurement decisions out of the product domain.

Adapters are where vendor churn is absorbed. Fields get renamed, retyped, and deprecated; endpoints and rate limits change. Contract tests and a fixed set of regression properties catch that before a product does.

Two things must survive resolution. The first is provenance: which upstream system supplied each field. Standard originating and source system metadata exists precisely so a consumer can tell which system a record came from, and it should be asserted on rather than discarded during normalization.³⁷ The second is rights, which do not merge. One source may be displayable externally, another internal-only, another usable for retrieval but not training — and a canonical record that cannot name its upstream providers cannot enforce any of it.⁸

That also buys resilience. When the primary source is unavailable, throttled, or not permitted for this particular use, the gateway can serve an approved cached value, fall back to a secondary, return the answer with reduced confidence, or return an explicit unresolved state — which is always better than manufacturing certainty.

Agents make the gateway mandatory

Handing a model several raw property APIs and letting it decide what to trust reproduces the entire resolution problem inside a prompt, where it cannot be tested, versioned, or audited. The governed alternative is narrower and duller: one interface, a canonical value, its provenance, and its confidence.

It is also the only version you can evaluate. Proving a property AI reached the right conclusion, about the right property, on evidence it was permitted to use, is its own discipline — and it depends on the answer carrying that context in the first place.⁹

Buy the access. Own the resolution.

Recreating county-by-county acquisition is rarely a good use of engineering time. It is undifferentiated work, and the market now does it at a scale most teams cannot match economically.

What differentiates is everything above that line: canonical identity, field-level provenance and time, an explicit conflict policy, routing by field, and continuous measurement of every provider. Those are the assets that make a vendor replaceable, a product explainable, and an answer defensible.