Sold Prices API: Working with HM Land Registry Data

HM Land Registry Price Paid Data is one of the most useful foundations for property research in England and Wales. It records completed residential transactions that were sold for value and lodged for registration. A sold prices API turns that large public dataset into a searchable service for one property, street, postcode or wider area.

The API removes the work of downloading, updating and querying multi-gigabyte files, but it does not remove the need to understand the data. A completed price is not an asking price, a current valuation or proof that two homes are comparable. Recent months can also be incomplete while registrations arrive.

This guide explains how to use the Property Insights sold-price endpoints without overstating what a transaction record means.

What Price Paid Data contains

The official HM Land Registry Price Paid Data download page provides transaction records from January 1995 onwards. Fields include the price, transaction date, address, property type, tenure category, new-build status and transaction category.

The dataset covers residential sales in England and Wales that were sold for value and lodged for registration. It does not represent every transfer of property. The official access guidance lists exclusions such as gifts, some transfers between parties, discounted right-to-buy sales and transactions that have not been lodged.

That leads to a simple editorial rule: describe a result as a recorded Price Paid transaction, not as a complete ownership or transfer history.

If the application republishes the data, follow the required attribution and Open Government Licence terms. An API contract can simplify access, but it does not cancel source licensing obligations.

Sold price, asking price and valuation are different

Property interfaces often place several prices side by side. Each answers a different question:

Figure	What it means
Asking price	The amount a seller or agent is currently seeking
Agreed price	The amount negotiated, which may still be subject to completion
Sold price	The transaction amount recorded after completion and registration
Automated valuation	A modelled estimate for a stated date
Surveyor valuation	A professional opinion prepared for a defined purpose

Do not use the latest recorded sold price as today's value without adjustment and explanation. A home sold years ago may have been extended, divided, renovated or affected by market change.

The sold price is evidence. A valuation process decides how relevant that evidence is.

Choose the property or area endpoint

Property Insights provides two related search patterns.

Property sold-prices search

The property sold-prices endpoint centres a search on a postcode and supports filters such as radius, bedrooms, property type, price range, result limit and earliest date. It suits a property-detail screen or local evidence panel.

curl --get "https://propertyinsights.co.uk/api/v1/property/sold-prices" \
  -H "x-api-key: $PROPERTY_INSIGHTS_API_KEY" \
  --data-urlencode "postcode=EX1 2AB" \
  --data-urlencode "radius=1" \
  --data-urlencode "propertyType=Terraced" \
  --data-urlencode "since=2024-01-01" \
  --data-urlencode "limit=25"

Area sold-prices search

The area sold-prices endpoint supports postcode area or exact postcode searches with street, property type, price, new-build, lookback, limit and offset filters. It is better for a market table, export or paginated research tool.

curl --get "https://propertyinsights.co.uk/api/v1/area/sold-prices" \
  -H "x-api-key: $PROPERTY_INSIGHTS_API_KEY" \
  --data-urlencode "area=EX1" \
  --data-urlencode "type=T" \
  --data-urlencode "months=24" \
  --data-urlencode "limit=100" \
  --data-urlencode "offset=0"

Use a clearly fictional postcode in documentation and demos. Production logs should avoid copying a complete customer address unless it is necessary for investigation.

HM Land Registry transaction data flowing into a sold prices API

The API makes the dataset searchable; the source coverage and registration process still define the result.

Apply filters in a deliberate order

Filters should support the user's research question rather than produce an apparently convenient number.

Geography

Start with the smallest sensible area. An exact postcode or street may work in a dense market. A rural property may need a wider radius or longer timeframe. Avoid widening both at once because it becomes difficult to understand why the result changed.

Transaction date

Use an explicit lookback or since date. Recent sales are generally more relevant to current market conditions, but the newest months can be incomplete. A longer window adds evidence while increasing the need for market adjustment.

Property type

Detached, semi-detached, terraced and flat transactions should not be combined without a reason. The area endpoint uses HM Land Registry type codes, while the property endpoint accepts descriptive types. Follow the documented contract for each route.

Price range

Price filters can reduce irrelevant outliers in an exploratory tool. Do not use a narrow range derived from the expected answer, since that can hide evidence that challenges the assumption.

New-build status

New builds can carry a premium and may represent a different product from older housing. Keep their status visible or filter them deliberately.

Bedrooms

Bedroom information can enrich a local search where supported, but do not assume HM Land Registry Price Paid Data itself contains a bedroom count. Enrichment may come from another source and can have different coverage.

Registration lag and recent-month incompleteness

A sale does not appear instantly when keys change hands. The official guidance says the time between sale and registration varies and commonly ranges from weeks to months. The most recent monthly releases are therefore incomplete.

This affects products in several ways:

A "last 30 days" count is not a complete measure of market activity.
A recent property sale may be absent even when the customer knows it completed.
Results for the same period can change as later registrations arrive.
A dashboard should show the data's as-at or retrieval date.

Do not label a monthly fall in newly published records as a market crash without accounting for registration delay. For trend analysis, use sufficiently mature periods and document the method.

When a user says a sale is missing, explain the registration process and offer a later refresh. Do not create a manual transaction that looks like an official record unless it is clearly labelled as user-supplied.

Corrections, duplicate-looking rows and address changes

Price Paid Data can be corrected. A complete ingestion process needs to handle updates and deletions from source releases rather than append every monthly row forever.

Two records that look similar are not automatically duplicates. A property can sell more than once, and an address can change formatting between transactions. Conversely, a converted property may retain part of an older address while representing a different dwelling.

When presenting history:

Preserve the transaction identifier where available.
Sort by transaction date, not ingestion date.
Show property type and tenure category beside the price.
Keep the full address used by the record.
Avoid merging rows only because address and price match.
Retain the source update date for audit.

If your application maintains its own Price Paid copy, reconcile source changes. If it consumes the Property Insights API, follow the response contract and avoid maintaining a second conflicting truth without a clear reason.

Raw sold prices versus sold comparables

A sold-price search returns transaction evidence that matches filters. A sold comparables API goes further by helping identify transactions relevant to a subject property.

Use raw sold prices when the user wants to:

Browse street or area history.
Build a transaction map.
Count sales by type or price band.
Export filtered records.
Investigate one property's recorded history.

Use comparables when the user wants to:

Support a current valuation.
Find similar nearby homes.
Rank evidence by relevance.
Explain why some transactions were included or excluded.

The distinction protects users from treating the nearest expensive home as proof of value. Proximity alone does not account for size, condition, tenure or property type.

Area sold price analysis with property type and date filters

Area searches need visible filters, pagination and an as-at date.

Designing pagination and exports

The area endpoint supports limit and offset. Keep those values within the documented bounds and return pagination metadata to the client. Do not fetch every row into the browser and hide most of them with front-end filtering.

For CSV exports:

Apply the same server-side authorisation as the on-screen query.
Limit the fields to the user's stated purpose.
Include filter criteria and export time.
Preserve source attribution.
Prevent spreadsheet-formula injection when writing text cells.
Avoid adding customer notes or internal identifiers unless requested.

Large exports create privacy and licensing considerations even when individual transaction records are public. Define the user's need before providing bulk access.

Product use cases

Local market dashboards

Show transaction volume, median price and type mix for mature periods. Explain the lookback, geography and new-build treatment.

Estate agent preparation

An agent can review recent street sales before an appointment. The final valuation still requires property-specific inspection and local judgement.

Investment screening

Investors can compare asking price with local sold evidence, then move to comparables and a modelled valuation. This is more reliable than using a postcode average alone.

Portfolio monitoring

Transaction evidence can update market context around held properties. Avoid describing an inferred portfolio value as realised value.

Research and editorial work

Price Paid records can support local market analysis when the source, period and incompleteness are disclosed. For commercial-property limitations, see the guide to commercial real estate sold prices.

Sold prices API checklist

Choose the property or area endpoint for the actual user task.
Show filters, source and as-at date.
Distinguish asking, sold and modelled prices.
Account for registration delay in recent periods.
Use pagination for area results.
Keep new-build and property-type treatment visible.
Do not imply that all transfers appear in Price Paid Data.
Preserve source attribution.
Keep API credentials on the server.
Test corrections, repeated sales, changed addresses and empty result sets.