Property Due Diligence API Checklist for UK PropTech Teams

A property due-diligence screen can contain dozens of facts, scores and estimates. The difficult engineering problem is not fitting them on one page. It is resolving the correct property, calling services in the right order, handling partial coverage and showing the user which statements are facts, calculations or modelled opinions.

A property due diligence API workflow should begin with the customer's decision. An investor screening a listing needs a different level of evidence from a conveyancer reviewing title documents. An automated data pack can support early research, but it does not replace legal enquiries, a survey or professional advice.

Define the decision before selecting APIs

"Property due diligence" is too broad to be one requirement. Write down the decision, audience and acceptable uncertainty.

Examples include:

An investor deciding whether to spend time on a viewing.
An agent preparing for a valuation appointment.
A lender triaging properties for manual review.
A buyer comparing the running costs and local context of two homes.
A PropTech product generating a client information report.

Then define which questions structured data can answer. A screening tool may need address, recent sales, valuation range, EPC, Council Tax and planning constraints. A legal transaction needs searches, title documents and professional interpretation beyond that API set.

Do not add a source only because it is available. Each call adds cost, latency, failure states and information the user must interpret.

Resolve property identity first

Every downstream result depends on the subject property. Start with a confirmed UPRN or a complete address and postcode.

A sensible identity stage is:

Validate the input format.
Resolve the address through the UPRN address API.
Display the canonical address.
Ask for confirmation where several units are possible.
Store the UPRN and original input.
Stop if the property cannot be identified safely.

Do not start several paid enrichment calls while the customer is still typing. Trigger them after a deliberate selection or server-side confirmation.

For title-boundary work, property identity may lead to more than one relevant title. The property boundary API supports title selection where an address has multiple matches. General boundary geometry is useful context but not surveyed legal-boundary evidence.

Separate facts, estimates and indicators

The interface should tell users what kind of result they are reading.

Sourced property facts

Examples include a dated EPC record, Council Tax band, recorded sold transaction or UPRN-linked address. These still need source dates and coverage notes.

Calculations

Monthly Council Tax equivalents, price per square metre and SDLT calculations are derived from inputs and rules. Show the inputs and calculation date.

Modelled estimates

Automated valuation, renovation uplift and some market scores are estimates. Show ranges, assumptions and confidence.

Context indicators

Crime counts, school proximity, deprivation and liveability measures describe an area or dataset. They should not be converted into claims that a property is safe, suitable or guaranteed to grow.

Use visual labels and explanations rather than one undifferentiated "property score".

Recommended call order

Some calls depend on identity, while others can run in parallel after the property is confirmed.

Recommended call order for a multi-API property workflow

Resolve identity first, then request independent evidence in parallel before composing the result.

Stage 1: validate and resolve

Address and UPRN.
Coordinates or title selection where required.

Stage 2: property-level evidence

Stage 3: modelled analysis

Property valuation.
Property analysis.
Renovation or purchase scenarios.

Stage 4: local context

Crime.
Schools.
Planning constraints.
Broadband and mobile coverage.
Demographics, deprivation and liveability.

Stage 5: compose and review

Merge by confirmed property record.
Attach source and retrieval dates.
Surface warnings and missing sections.
Apply human review rules.
Render the customer view or private PDF.

The exact order can change. For example, a product may use EPC floor area before valuation. Document dependencies so future developers do not parallelise a call that needs a prior result.

Parallel calls versus dependent calls

After identity is confirmed, independent services can often run concurrently. This reduces the time spent waiting for a full screen.

Do not put every call in one Promise.all that fails the whole page when one optional source returns an error. Use settled results and classify required versus optional sections.

Conceptually:

const results = await Promise.allSettled([
  getEpc(property),
  getCouncilTax(property),
  getSoldComparables(property),
  getPlanningConstraints(property),
  getNearbySchools(property)
])

The server can then return successful sections with warnings for unavailable optional data. A valuation call that requires EPC-derived floor area should run after the relevant field has been resolved, with a documented fallback if it is missing.

Use timeouts per service. An optional school search should not hold the entire result open indefinitely.

Design for partial results

No large property-data workflow has perfect coverage. A resilient product makes missing data explicit.

Each section should have a status such as:

Available.
No matching record.
Unsupported location.
Temporarily unavailable.
Stale or expired.
Low confidence.
Requires user confirmation.

Avoid replacing unavailable sections with zeros. Zero recorded crimes and crime data unavailable are different. Council Tax band not found is not Band A. No comparable sales is not a valuation of zero.

For generated reports, decide which sections are required. The Property Information Pack API can return a partial report with source warnings when optional data fails. Customer-facing workflows should show that state before download.

Caching and freshness

Sources change at different rates. One global cache time is rarely appropriate.

Consider:

Address identity changes infrequently but needs a correction path.
Council Tax rates are tax-year specific.
EPC records change when a new certificate is lodged.
Sold transactions arrive after registration and can be corrected.
Crime and economic indicators have their own release periods.
Modelled valuations should include an as-at date.

Cache keys must include parameters that change meaning, such as tax year, lookback period, geography and property type. Store retrieval time and source date separately. Retrieval time says when your system called the API; source date says when the underlying fact or period applies.

Do not overwrite historic report snapshots with refreshed values. Reproducibility is part of due diligence.

Credit control and rate limits

Property calls have different credit costs and no-data billing behaviour. The server should be the single authority for deciding when to call an endpoint.

Useful controls include:

Do not request data until the property is confirmed.
Deduplicate identical in-flight requests.
Cache according to terms and business need.
Set a maximum cost for one workflow.
Reserve bundled report credits through the documented API.
Track the returned billing metadata rather than deducting again locally.
Warn account owners before balances run out.

Do not expose an unrestricted proxy route that accepts any upstream path. Map the exact permitted actions and validate all inputs.

Security, privacy and logging

Keep x-api-key on the server. Apply authentication and account authorisation to private properties, portfolio records and reports. A public property fact does not make a customer's saved research public.

Logs should support diagnosis without becoming a second property database. Record endpoint, status, duration, credit result, internal property ID and a limited source reference. Avoid full report bodies, customer notes and API keys.

For address inputs, apply length limits and normalisation. For generated filenames, avoid complete addresses and personal names. For exports, protect against spreadsheet-formula injection and restrict fields to the requested purpose.

Present evidence without overwhelming the user

A good summary page answers the main decision first, then lets the user inspect evidence.

Use a hierarchy such as:

Confirmed property and report date.
Key decision figures with type labels.
Warnings and missing evidence.
Valuation and sold comparables.
Running costs and energy.
Boundary and planning context.
Local indicators.
Sources and limitations.

Property dashboard separating factual records, estimates and warnings

Users should be able to distinguish sourced records from modelled values and unavailable sections.

Do not use colour alone to communicate status. Add text labels and accessible icons. Avoid red "risk" badges for neutral facts that require interpretation.

Observability and quality checks

Monitor the whole workflow as well as individual endpoints:

Identity match and correction rate.
Section availability by country and property type.
Latency by endpoint and full workflow.
Credit use per completed customer result.
Low-confidence valuation rate.
Partial-report rate and missing sections.
Customer support disputes by source.
Cache age and refresh failures.

Use synthetic fictional properties for routine checks. Do not repeatedly probe a team member's or customer's home.

When match quality changes, investigate identity and source coverage before changing the valuation model. Many apparent analytics problems begin with the wrong property.

Due-diligence API checklist

Define the decision, user and success criterion.
Resolve and confirm property identity first.
Separate facts, calculations, estimates and indicators.
Document dependent and parallel calls.
Treat partial results as explicit states.
Store source and retrieval dates.
Cache by meaningful parameters.
Control credits and prevent duplicate calls.
Keep credentials and private results server-side.
Add human review for unusual or high-stakes decisions.