By Raf Howery | Kukun

If you’re evaluating property data APIs for the first time, the market looks deceptively simple: several vendors, similar feature lists, wildly different prices. The reality is more complicated. What you’re actually choosing between is different data architectures, different coverage models, and very different answers to the question of what your use case actually requires.

This guide is written for technical buyers (developers, data teams, and product managers) who need to make an informed decision and explain it to their stakeholders.


What property data APIs actually deliver

A property data API gives you structured, machine-readable data about a specific address, on demand, via a standardized API call, without scraping public records yourself.

What’s in that data varies significantly by vendor. At the broadest level, property data breaks into several categories:

Property records: the baseline. Address, parcel ID, owner name, year built, square footage, lot size, zoning, assessed value. Available from most vendors.

Let's connect, and see how we can help you stay ahead of the market.

Contact us

Invalid email address.
Must be 10 digits.

How can we help? *

0 / 5000

Permit data: what work has been done at the property, when, and by whom. A roof permit, an HVAC replacement, a kitchen gut renovation, a new addition. Coverage and quality vary dramatically (see our separate post on permit data quality).

Valuation (AVM): automated valuation models that estimate current market value. Range from basic comparable-sales models to permit-enriched models that factor in renovation activity.

Condition scoring: algorithmic assessment of property condition based on permit history, system ages, and comparable activity. No physical inspection required.

System lifecycle: estimated remaining useful life of major systems (roof, HVAC, electrical) based on installation dates from permit records, typical lifespan models, and property age.

Market intelligence: ZIP-level demand and risk signals: inventory trends, days-on-market, price movement, investment activity.

Renovation and contractor data: permit-derived renovation history and contractor identity, useful for proptech platforms and servicer marketing.

Most vendors offer some subset of these. The questions are: which ones does your use case require, how good is the underlying data, and what does it cost to access them?


The join problem

Here’s where most buyers underestimate complexity: the primitives above are most valuable when used together.

A valuation without condition context is an estimate with unknown error bounds. A permit record without property age context doesn’t tell you whether the HVAC replacement is routine maintenance or a flag. A renovation trigger signal without valuation context doesn’t tell you whether the equity is there to support a HELOC.

Most vendors sell these as separate products with separate API calls, separate data contracts, and no native join. Your engineering team builds the join layer. That means latency, schema translation, error handling, and ongoing maintenance every time a vendor changes their data model.

The alternative is a provider that joins these primitives natively; one API call returns permit history, valuation, condition score, system lifecycle, and property records on any U.S. address. Your application gets a single response with everything it needs. No join layer required.

This is the most underappreciated architectural decision in property data API selection. Build the join yourself, or buy it pre-joined.


What to evaluate in a permit data provider

Permit data quality deserves specific attention because it varies more than any other primitive and is harder to audit without domain knowledge.

Source count: How many jurisdictions does the provider cover directly? A reseller’s ceiling is their upstream source’s coverage. Ask for the number of direct source integrations, not “jurisdictions covered”, the latter is often inflated.

Refresh cadence: How often is data updated? Biweekly refresh means a permit issued today may not appear in your system for two weeks. For risk and underwriting use cases, that lag is operationally significant.

Label quality: Raw permit descriptions are unusable for machine learning or rule-based systems. Ask how labels are assigned: keyword matching, ML classification, or manual review? And ask for the false-positive rate on a sample set in your target geography.

Schema stability: Permit data originates from thousands of different jurisdictions, each with its own format. A provider with a stable, consistent schema across all sources saves your team significant integration work.


Pricing models you’ll encounter

Property data APIs are priced in three main ways:

Per-call: You pay for each API call. Works well for low-volume or unpredictable workloads. Typical range: $0.08–$6.00/call depending on the primitive and provider.

Subscription tiers: Monthly fee for an included call volume. Works well for predictable, steady-state usage. Typically includes volume discounts at higher tiers.

Enterprise/custom: Annual contract, negotiated volume, custom SLA. Required for high-volume batch runs, portfolio-level pulls, or redistribution.

Watch for two traps in per-call pricing: hidden join costs (a single workflow requiring 4 primitives at 4 separate API calls costs 4x what a pre-joined response costs) and overage structures that spike your bill unpredictably.


Questions to ask every vendor

Before signing a data contract, get direct answers to these:

  1. How many direct source integrations do you have for permit data? (Not “jurisdictions covered”, direct integrations.)
  2. What is your median data lag from permit issuance to API availability?
  3. How are permit labels assigned, and what’s your false-positive rate?
  4. Is property context (valuation, condition, system age) joinable in a single call or separate API calls?
  5. What is your schema change policy, and how much notice do you give before breaking changes?
  6. For enterprise: what does the SLA cover, and who is my dedicated support contact?
  7. Can I test the data in my target geographies before committing to a contract?

What the right fit looks like by use case

Insurance underwriting: You need permit data with short refresh cycles, high coverage in secondary markets, and reliable labeling for HVAC, roof, and electrical permits. Condition scoring and system lifecycle are high-value additions. Native join with property records matters for workflow efficiency.

Mortgage origination and HELOC: Renovation trigger signals (recent permit activity on a property) are the primary use case. AVM and property records alongside permit data let you qualify the opportunity without multiple data pulls. Speed of data (refresh rate) matters because you’re acting on signals, not historical records.

Proptech and developer tools: Schema stability and API reliability are table stakes. Geographic query support (ZIP-level pulls) matters for market-view features. Full Knowledge Graph access lets you build richer products without maintaining multiple data vendor relationships.

Investment analytics: Market intelligence signals (ZIP-level renovation concentration, permit activity trends) combined with individual property data. Geographic query performance is critical for portfolio-level tools.


Before you sign

Three things before any data contract:

  1. Test in your actual geographies. Coverage claims are national averages. Quality in your specific markets may be significantly better or worse. A free or trial tier should let you validate before you commit.
  1. Audit a sample set. Pull 100 addresses you know and verify the permit history against public records for 10–20 of them. Any provider confident in their data should support this.
  1. Read the license terms. Property data contracts typically restrict redistribution and downstream use. Make sure your use case (especially if you’re building a product on top of the data) is covered.

→ Explore the Kukun Property Knowledge Graph at mykukun.com/developers Nine primitives · Single API call · Free tier: 20 calls, no credit card required

The Buyer’s Guide to Property Data APIs was last modified: October 7th, 2026 by Raf Howery