Real Estate & Property
Automated Property Valuation API
An estimated value with no confidence range is a guess with a decimal point. The useful version tells you how much to trust it, and when not to.
- Property portals
- Mortgage lenders
- Estate agency software
- Investors
- Insurers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Automated valuation is the single most requested feature in property software and the one most often shipped badly. The pattern is familiar: a model is trained on national transaction data, deployed everywhere, and produces a tidy figure for every address including the ones it has no business valuing. Users discover the weakness on the properties that matter most to them.
Accuracy in this problem is almost entirely a function of local data density. In a suburb of near-identical terraced houses with forty comparable sales in the last year, a well-built model will land within a few per cent. Move to a rural parish with three transactions in two years, or a converted barn with no comparable at all, and the same model is producing a number from essentially nothing — while still returning it with the same apparent authority.
There is also a structural data problem. Recorded transaction prices lag completion by weeks or months depending on the registry, do not always record the property's condition or whether it was an arm's-length sale, and rarely capture the extension built two years ago. A valuation model inherits every one of those gaps, and the honest response is to quantify and surface them rather than smooth them away.
Who buys this
Property portals, Mortgage lenders, Estate agency software, Investors, Insurers
What the API returns
What comes back
- Point estimate with a confidence interval, not a bare figure
- A data-sufficiency score for the location and property type, published with every valuation
- The comparable transactions used, with their adjustments itemised
- Adjustment breakdown: size, condition, floor, age, tenure, outlook
- Local market trend and the time adjustment applied to older comparables
- Rebuild and insurance-reinstatement estimates where that is the question being asked
- An explicit refusal state for properties the model should not value, with the reason
- Valuation history for the address, so revisions over time are visible
Endpoints
| Method | Path | Returns |
|---|---|---|
| GET | /v1/valuation | Value a property by address or identifier |
| POST | /v1/valuation | Value a property from supplied attributes |
| GET | /v1/valuation/comparables | Comparable transactions with adjustments |
| POST | /v1/valuation/batch | Portfolio or book-level revaluation |
| GET | /v1/markets/{area}/trend | Local price trend and index series |
| GET | /v1/coverage/{area} | Data sufficiency and expected accuracy for an area |
Request and response
illustrativeRequest
{
"address": { "line1": "14 Ashbourne Road", "postcode": "LS8 2QR", "country": "GB" },
"attributes": {
"property_type": "semi_detached",
"bedrooms": 3,
"floor_area_sqm": 94,
"tenure": "freehold",
"year_built": 1935,
"condition": "good",
"extended": true
},
"include": ["comparables", "adjustments", "coverage"]
}Response
{
"valuation": {
"estimate": 318000,
"currency": "GBP",
"confidence_interval_80": [296000, 341000],
"confidence_interval_95": [282000, 357000],
"as_of": "2026-10-22"
},
"coverage": {
"data_sufficiency": 0.86,
"band": "good",
"comparable_sales_12m": 37,
"expected_mape_for_area": 0.058
},
"adjustments": [
{ "factor": "floor_area", "effect": 14200 },
{ "factor": "extension", "effect": 9800 },
{ "factor": "condition", "effect": 4100 },
{ "factor": "time_index", "effect": -3600 }
],
"comparables": [
{ "address": "22 Ashbourne Road", "sold": "2026-07-18", "price": 309500,
"floor_area_sqm": 91, "adjusted_price": 316400, "distance_m": 110 },
{ "address": "7 Marlow Grove", "sold": "2026-05-02", "price": 324000,
"floor_area_sqm": 98, "adjusted_price": 319900, "distance_m": 380 }
],
"warnings": [
{ "warning": "extension_not_in_registry_record", "effect": "attribute_taken_from_request" }
]
}Where the data comes from
| Official transaction registries | Recorded sale prices from land registries and equivalent public records — the authoritative price source, with a publication lag that has to be modelled rather than ignored |
| Listing and asking-price data | Where licensed from portals or provided by you, useful as a leading indicator between registry updates; asking prices are not transaction prices and are treated separately |
| Property attribute data | Floor area, type, age, tenure and energy-certificate records, which supply the attributes the price model needs |
| Planning and building records | Extensions and conversions that changed a property after its last recorded sale, which the registry entry will not reflect |
| Geospatial and amenity data | Location features — transport access, school catchments, aspect, flood designation — drawn from licensed and open datasets |
| Your own valuation outcomes | Surveyor valuations and completed loan data where you hold it, which is the best available calibration and validation set |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- A hedonic regression and gradient-boosted ensemble, blended by a local-data-density weighting rather than applied uniformly everywhere
- Comparable selection on geographic and attribute distance with explicit, itemised adjustment for each difference
- Time adjustment using a locally estimated index, not a national one, since local markets diverge substantially
- Uncertainty quantified from local comparable dispersion, so the interval widens where the data is thin instead of staying nominal
- A hard refusal rule: below a data-sufficiency threshold, or for property types with no comparable population, the API declines to value
- Arm's-length-sale filtering to remove inter-family transfers, part-exchanges and repossessions that distort local comparables
- Backtesting on held-out completed transactions, with error reported by area, property type and price band rather than as one national figure
- Drift monitoring on prediction error by area, which is how a changed local market or a registry data problem gets noticed
What it changes for the business
Portal engagement
An instant valuation is one of the strongest lead-capture features a property portal can offer.
Faster lending decisions
A calibrated automated valuation supports desktop decisioning on the cases where accuracy is demonstrably adequate.
Cheaper portfolio revaluation
Book-level revaluation becomes a batch job rather than a surveyor engagement.
Honest triage
Knowing which properties the model cannot value tells you exactly where to spend a physical inspection.
How it fits into your product
How it embeds
- Single synchronous call by address for interactive use, with sub-second responses from a precomputed layer
- Batch endpoints for book revaluation across tens or hundreds of thousands of properties
- Comparable evidence returned in a form you can render directly in a report or a customer-facing page
- Address matching and geocoding handled inside the API, with an explicit unmatched state
- PDF valuation report generation where a document is part of your workflow
- Deployment inside your infrastructure where lending or customer data cannot leave
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 20 weeksDiscovery and feasibility
Weeks 1–3
This one depends heavily on data access, so we start by proving the sources exist, can be licensed for your use, and actually carry the signal the model needs. If they do not, you find out here.
Architecture and baseline model
Weeks 4–6
A written architecture and a baseline model measured against a holdout period, so you know what accuracy you are buying before the full build starts.
Production build
Weeks 7–16
Data pipelines, model training and serving, historical archive, validation harness, API, security, monitoring and documentation.
Validation and integration
Weeks 17–20
Backtesting against held-out history, accuracy reporting your team can audit, integration support and an agreed retraining cadence.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
How accurate is it?
It depends entirely on local transaction density, and any vendor quoting one national accuracy figure is hiding the variation that matters. In dense, homogeneous urban areas with plenty of recent comparable sales, error in the region of five per cent is achievable. In thin markets — rural areas, unusual property types, high-value homes with no real comparable — accuracy degrades badly, sometimes to the point where the estimate carries no useful information. We publish a data-sufficiency score and a widened interval with every valuation for exactly this reason.
What happens for properties you cannot value?
The API refuses, with a reason. Below a minimum comparable count, or for property types with no comparable population at all, returning a number would be worse than returning nothing — someone downstream will treat it as a valuation. A refusal tells you to instruct a surveyor, which is the correct answer.
Can this replace a surveyor?
No, and we would not position it that way. It can triage, support desktop decisions within a documented accuracy envelope, and revalue a portfolio between physical inspections. For a lending decision at the margin, or for an unusual property, a physical valuation is doing something the model cannot. Where it sits in your decision process is a question for your risk and regulatory teams.
How current are the figures?
Transaction registries publish with a lag — typically weeks to a couple of months depending on the jurisdiction — so the most recent market movement is always partly unobserved. Where licensed listing data is available we use it as a leading indicator, flagged as such. Every response carries an as-of date so the lag is never invisible.
Does it know about an extension or a renovation?
Only if the record exists or you tell it. Planning and building-control records capture some changes; many refurbishments leave no trace in any dataset. If you supply attributes they are used and the response marks which values came from the request rather than from a record, so you can see what the estimate is resting on.
Related blueprints
Rental Price Intelligence API
Expected rent for a property, neighbourhood comparisons and rental trend series, as an API letting agents and investors can call per address.
Property Investment Scoring API
Yield, vacancy risk, expense estimates and appreciation scenarios for a property or a portfolio, returned as a scored investment assessment.
Construction Cost Estimation API
Material, labour and whole-project cost estimates with regional adjustment and a stated uncertainty range, for early-stage feasibility and pricing.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.