Valuation Concepts

This guide explains the scope of the Valtaic Property Valuation API, the available valuation workflows and the meaning of its principal response fields.

For model scope, performance evaluation and responsible-use considerations, see Compliance & assurance. This page focuses on the API concepts.

Valuation Scope

The API returns an estimate of residential market value for a specified property as at a specified date. It is intended for initial pricing, portfolio analysis, digital property journeys and other decision-support workflows.

The estimate is not a prediction of the price at which a particular transaction will complete. An achieved sale price may differ because of timing, negotiation, incentives, condition, legal matters or the circumstances of the buyer and seller.

Supported Properties and Locations

The service covers residential property in England and Wales, including:

• detached houses and bungalows;
• semi-detached houses and bungalows;
• terraced houses and bungalows;
• flats and maisonettes.

Within supported locations, unusual characteristics, large land holdings or insufficient evidence may lead to a manual referral. Unsupported geography is a rejection, not a referral. Farms and materially mixed-use assets are outside the intended scope; do not submit them as ordinary houses or flats and rely on the API to discover an unreported use.

Valuation Dates

The requested date is the date being assessed, not a selection of the model or information available historically. Requests use the active valuation release. See Versioning and Releases for the permitted date window and the distinction between a past-dated estimate and a historical evaluation.

Choosing an Endpoint

Choose an endpoint according to the property being valued and the required response:

Use an existing-property endpoint for a registered home, including one that has been extended or refurbished. Use a development endpoint only for a proposed or unregistered property that does not yet have a UPRN.

Point Estimate, Range and Confidence

These outputs answer different questions:

• Point estimate: the estimated market value on the requested date.
• Prediction range: the lower and upper values associated with the estimate.
• Confidence: an assessment of the strength of the available evidence.

A narrow range and high confidence may occur together, but they are not the same measure. Neither is a guarantee of a future sale price, lending decision or transaction outcome.

Input Precedence and Stored Data

Explicit customer inputs take precedence over stored property data. Stored data is used only when options.use_stored_data=true, the field is eligible, the customer has not supplied a value and the API key has the required scope. The conditional rules still apply: for example, plot area is ignored for flats, and new-build status fixes the construction-age band.

The response identifies stored values applied to the request, submitted values ignored as inapplicable and values derived by the API. See Identity and Stored Data for the complete rules.

Comparables and Supporting Evidence

The standard endpoints can return comparables and location context when requested. These fields help customers understand the result, but they do not constitute a survey or a complete valuation report.

comparables_limit controls how many comparable transactions are returned. It does not change the point estimate.

Manual Referrals

A structurally valid request may still fall outside the supported automated market. In that case, the API returns status=referred without a point estimate. Common reasons include unusual property characteristics, limited evidence and low market liquidity.

A referral is an expected response, not a system error. Route it to an appropriate manual valuation process rather than resubmitting the same request.

Valuation Releases

The public API version and valuation release are separate. Valuation response envelopes include a release_id; batch rows share the identifier on their envelope. Validation, authentication and transport errors need not include it.

Values may change between releases as market information and service coverage are updated. Persist the release_id with every valuation; an identical request is not guaranteed to return the same value under a later release. The release ID does not identify every API software update, so retain the original response too.

Development Valuations

Development endpoints value proposed properties on an as-complete new-build basis. They do not require a UPRN, do not resolve an existing property identity and do not inherit stored subject-property attributes. Site latitude and longitude are required alongside the postcode. The newest construction-age band and typical modern fabric are applied automatically.

Development results should be considered alongside professional judgement on specification, completion timing, incentives, service charges, legal terms and sales risk.

Limitations and Appropriate Use

Property records may contain delays, omissions or measurement differences. Interior condition, title restrictions, defects and service charges may not be fully represented in an automated request.

The API is suitable for initial pricing, portfolio monitoring, customer journeys, triage, analytics and decision support within an appropriate governance framework. It is not a substitute for a regulated valuation, physical inspection, legal due diligence or credit policy where those are required.

Auditability

Persist the request and response together with the optional request reference, server-generated execution and valuation IDs, release ID and valuation date. For batch and job workflows, also retain the row and job identifiers. These records establish what was requested, which release answered and how the API classified the result.