Development Valuations

Development endpoints return as-complete new-build valuations for proposed or unregistered residential properties. A proposed unit may not yet have a UPRN or an existing property record, so it cannot use the standard identity process.

When to Use Development Endpoints

Use development endpoints for:

• a proposed house or flat that has not been registered;
• an early unit schedule where UPRNs do not yet exist;
• an as-complete valuation based on proposed physical specifications;
• a development sensitivity run across multiple unit types.

Do not use a development endpoint solely because an existing home has been extended or refurbished. Use an existing-property endpoint with its current UPRN and physical attributes.

Dedicated Routes

Required scope: avm:development. Development jobs submitted to /v3/valuation-jobs require both avm:value and avm:development.

Schema Differences

Supply property.latitude and property.longitude as WGS84 numbers for the site, together with its postcode. Both coordinates are required; latitude must be between -90 and 90 and longitude between -180 and 180. The postcode must describe the same location and fall within the supported coverage.

The development property object omits:

• uprn;
• build_status.

Development options omit:

• use_stored_data.

These exclusions prevent a proposed unit from inheriting stored attributes belonging to an existing property.

The request also excludes fabric and energy.construction_age_band. These settings are fixed by the API, not customer inputs. Sending any excluded field, even with null or the same value the API would apply, is a validation error. In a batch or development job, the affected row is rejected without preventing valid rows from being valued. Invalid shared options reject the request envelope before any rows are processed.

The optional energy object accepts efficiency scores, energy consumption, solar PV supply percentage and, where applicable, extension count.

Automatic Rules

The development endpoints automatically apply the following rules:

identity source = development_mode
UPRN = absent
build status = new_build
construction age band = 2022_onwards
fabric = typical modern specification
stored subject-property inheritance = disabled
address resolution = not performed

The postcode establishes coverage and local market context; the coordinates locate the site for comparable retrieval. Building number/name and street may be supplied as customer references, but they are not used to resolve an existing property identity. There is no subject-property repeat-sale history.

Modern fabric means high estimated roof insulation, insulated walls and floors, mostly or fully double glazing, and efficient lighting, with the good preset. It does not assume solar panels, a heat pump or luxury finishes. Fabric and the construction-age band are applied internally and recorded in input_resolution; they are not configurable request fields.

Example Request

{
  "request_reference": "scheme-a-unit-01",
  "options": {
    "include_comparables": true,
    "comparables_limit": 5
  },
  "property": {
    "valuation_date": "2026-09-08",
    "postcode": "OX1 1AA",
    "latitude": 51.750236,
    "longitude": -1.267349,
    "type": "F",
    "subtype": "flat",
    "title_tenure": "leasehold",
    "building_number_or_name": "Unit 01",
    "street": "Proposed Avenue"
  },
  "occupancy": {
    "status": "owner_occupied"
  },
  "size": {
    "floor_area_m2": 78,
    "bedrooms": 2,
    "living_rooms": 1
  },
  "energy": {
    "current_efficiency_score": 86,
    "potential_efficiency_score": 91,
    "consumption_kwh_m2_year": 70,
    "solar_pv_supply_percent": 15
  },
  "lease": {
    "mode": "simple",
    "years_remaining": 250
  }
}

Do not supply construction_age_band; the current new-build band is applied automatically. Plot area and extension count do not apply to flats. For a flat, storeys means the number of levels within the unit.

Development Batch

{
  "requests": [
    {
      "request_reference": "scheme-a-unit-01",
      "property": {
        "valuation_date": "2026-09-08",
        "postcode": "OX1 1AA",
        "latitude": 51.750236,
        "longitude": -1.267349,
        "type": "F",
        "subtype": "flat",
        "title_tenure": "leasehold"
      },
      "occupancy": {
        "status": "owner_occupied"
      },
      "size": {
        "floor_area_m2": 78,
        "bedrooms": 2,
        "living_rooms": 1
      },
      "lease": {"mode": "simple", "years_remaining": 250}
    }
  ]
}

Use optional request references based on your scheme and unit identifiers. Results remain in request order and each receives a server valuation_id.

Confidence and Supporting Evidence

A proposed unit cannot be linked to an existing subject-property record. Confidence may therefore differ from that of established properties in the same postcode.

Comparables provide supporting context; they do not guarantee that the proposed scheme will transact at the estimate. Specification, completion timing, sales pace, incentives, service charges and absorption risk may require a professional development appraisal.

Comparables may include existing homes as well as new builds; they are not restricted to new-build sales. Coordinates enable the search but do not guarantee a particular number of suitable sales. Supply include_comparables=true to return the available evidence.

A valuation may succeed without displayed comparables. Check the response status rather than treating an empty comparable list as a failed valuation.

See Latency and Throughput for single-property and unit-schedule timings, and Limits and Safeguards for payload limits and timeout handling.

Legal Tenure

Proposed leasehold properties still require lease details. Use simple mode for known years remaining at valuation or detailed mode for known legal dates.

The API does not model future ground rent, service-charge structures, restrictive covenants or sale incentives through the lease object.