Property Valuation API UK: AVMs, Confidence and Evidence

A property valuation API can return an estimate in seconds. The speed is useful, but the number alone is not enough. Product teams need to know which property was matched, what evidence supported the estimate, when the valuation applies and how the system signals weak data.

An automated valuation model, often shortened to AVM, is best treated as a modelled opinion within a defined range. It is not a survey, mortgage offer or formal RICS valuation. When the difference matters financially, the interface should make that distinction clear before the customer acts.

This guide explains how to integrate the Property Insights valuation endpoint and present the result responsibly.

What an automated valuation can answer

An AVM can help answer questions such as:

What value range is supported by recent local evidence?
How has the wider market moved since a prior recorded sale?
Does an asking price sit above or below a modelled estimate?
Is there enough evidence for an automated first pass?
Which properties should be referred for manual review?

It cannot reliably inspect condition, finish, views, layout quality, defects or every planning and title issue. Structured data may record bedrooms and floor area, but it rarely captures how a particular extension works in practice.

The right role is triage and evidence-led analysis. The application should use confidence and limitations to decide when an estimate can be shown as a useful guide and when a human needs to inspect the property.

Inputs that materially affect the result

The Property Insights valuation API requires a postcode and address. Optional fields include city, historical lookback, extension area and renovation uplift.

A broader property-analysis workflow may also know property type, bedrooms, floor area and asking price. Whatever the route, input quality matters.

Address and postcode

These identify the subject and local market. Include the complete flat or building detail. A valuation for the wrong unit can still look plausible.

Property type

Flats, terraces, semi-detached and detached homes trade in different segments. Do not substitute a postcode's dominant type when the subject type is unknown.

Floor area

Area allows price-per-square-metre comparison. Keep the source and measurement date. EPC-recorded area is useful but is not the same as a new measured survey.

Bedrooms

Bedroom count helps comparison, particularly where floor-area coverage is incomplete. It should not replace size because two three-bedroom homes can differ greatly.

Valuation date and lookback

The model needs enough historic evidence while remaining relevant to the intended valuation date. Store the date with the result so it is not mistaken for a permanent property fact.

How the evidence fits together

Property valuation models can use several forms of evidence. The exact implementation belongs in the current API documentation and methodology, but the product concepts are consistent.

Sold comparables

Recent, similar transactions anchor the estimate in actual completed sales. Their relevance depends on type, distance, recency, size and other available attributes.

House Price Index context

HPI can adjust older evidence for broad market movement. It describes an area or category, not the exact path of one property.

Floor-area evidence

Price per square metre can help compare differently sized homes. It is most useful when area measurements are consistent and the property type is similar.

Prior sale history

A previous transaction provides a subject-specific anchor, but the building and market may have changed since that date.

Sold comparables, market trends and floor area feeding an AVM

Different evidence sources should support the estimate without hiding their dates or limitations.

Request a valuation

The endpoint accepts a postcode, address and optional modelling inputs.

curl --get "https://propertyinsights.co.uk/api/v1/property/valuation" \
  -H "x-api-key: $PROPERTY_INSIGHTS_API_KEY" \
  --data-urlencode "postcode=EX1 2AB" \
  --data-urlencode "address=12 Example Street" \
  --data-urlencode "months=36"

For an explicit scenario, optional extension and renovation assumptions can be supplied:

curl --get "https://propertyinsights.co.uk/api/v1/property/valuation" \
  -H "x-api-key: $PROPERTY_INSIGHTS_API_KEY" \
  --data-urlencode "postcode=EX1 2AB" \
  --data-urlencode "address=12 Example Street" \
  --data-urlencode "extensionArea=18" \
  --data-urlencode "renovationUplift=8"

The address is fictional. Keep real credentials on the server and validate the optional values against the documented ranges.

Store the request inputs with the result. If a user later changes the assumed extension from 18 to 25 square metres, that is a new scenario rather than a correction to the original valuation.

Point estimate, range and confidence

A single estimate is easy to display and easy to misuse. A range communicates that the model is working with incomplete evidence.

The result page should show:

Central estimate.
Lower and upper range where returned.
Confidence score or label.
Valuation date.
Subject address.
Main evidence and source dates.
Warnings or missing inputs.

Confidence is not the probability that a sale will complete at the central estimate. It reflects the model's evidence and fit according to its methodology. A high-confidence estimate can still differ from a negotiated sale price because buyers, condition and transaction circumstances matter.

Define product rules around confidence. For example, a low-confidence result may show a wide range and recommend manual review instead of placing the central estimate in a prominent lead-generation headline.

Low-evidence and conflicting cases

Automated valuation is hardest when:

Few similar properties have sold recently.
The property is unusual or mixed use.
The address matches ambiguously.
Floor area or type is missing.
The property has been substantially altered.
New-build transactions dominate the local evidence.
Comparable prices are widely dispersed.
A prior sale conflicts with the current property description.

Do not solve every case by widening the search until a number appears. Wider geography and older transactions can reduce relevance. The model should expose weaker confidence, and the product should respect it.

If evidence conflicts, show the discrepancy. An EPC describing a flat while the input says detached house is a reason to stop and verify identity, not average the two.

Renovation and extension scenarios

Scenario modelling is valuable for investors and developers, but assumptions must stay visible.

An extension-area input does not confirm that planning permission exists, that the work is structurally possible or that buyers will pay a fixed amount per square metre. A renovation uplift percentage is a user or business assumption, not an observed future sale.

Present scenario output as:

Base modelled value.
Assumed extension area.
Assumed renovation uplift.
Scenario estimate or range.
Costs excluded from the estimate.
Planning, design and valuation limitations.

Use the dedicated renovation uplift calculator API when the product needs a transparent standalone calculation. Do not mix a scenario estimate into the current-value field.

AVM versus other valuation routes

Estate agent market appraisal

An agent can inspect condition, buyer demand and current competing listings. The opinion may also reflect a marketing strategy, so record its date and purpose.

Surveyor or RICS valuation

A qualified professional prepares a valuation for a defined purpose and follows relevant standards. Lenders, courts and tax matters may require this route rather than an online estimate.

Automated valuation

An AVM is consistent, quick and useful for screening or portfolio analysis. It works best where structured attributes and comparable evidence are strong.

These methods can complement each other. The mistake is presenting them as interchangeable.

Analyst reviewing an automated property valuation and its evidence

Human review adds property condition and purpose-specific judgement that structured data may not contain.

Build an auditable result

A valuation should be reproducible enough for support and monitoring.

Store:

Subject identifier and canonical address.
Input attributes and their sources.
Request time and valuation date.
API or model version where provided.
Estimate, range and confidence.
Comparable references or evidence summary.
Scenario assumptions.
Warnings and review status.

Do not store the API key or unnecessary customer details with the valuation. Apply authorisation before returning saved results, especially in a portfolio or client-report product.

Monitor accuracy only against an appropriate outcome. Comparing every estimate with an asking price measures agreement with sellers, not valuation performance. Completed transaction prices are more useful, but registration lag and property changes must be considered.

Responsible product wording

Use labels such as "automated estimate", "modelled range" and "as at". Avoid "guaranteed value", "exact value" or "approved valuation".

A concise limitation can say:

This automated estimate uses available property and market data. It is not a survey, mortgage valuation, legal report or RICS valuation. Property condition and features not present in the data may affect value.

The wording should appear beside the result, not only in a distant terms page.

For client-ready output, the Property Information Pack API includes source and limitation sections alongside valuation and sold evidence.

Property valuation API checklist

Confirm the complete subject address.
Preserve input sources and valuation date.
Show a range and confidence, not only a point estimate.
Keep comparable evidence accessible.
Stop on conflicting property identity.
Treat renovation values as explicit scenarios.
Define manual-review rules for low confidence.
Distinguish AVM, agent appraisal and formal valuation.
Keep credentials and private reports server-side.
Monitor against suitable completed-sale outcomes.