UK Property Market Data API - Prices, Rents, Yields, EPC

Turn a list of UK postcodes into a dataset: what sells, what rents, what it yields, who owns it, and what the council has already said yes to.

What it collects

• Local market: live asking prices and sold prices, long let and HMO rents, commercial quoting rents, rental yields, up to seven years of capital growth, sales and rental demand, price and growth per square foot, estate agent market share, local housing allowance rates and national market indicators.
• Planning and constraints: planning applications filtered by project type, application type, outcome, age and radius; listed buildings by grade; conservation area and green belt checks; flood risk from rivers and sea; build cost and rebuild cost per property.
• Buildings and energy: EPC ratings and known internal floor areas for every property in a postcode.
• Ownership and identifiers: UPRNs across a postcode area with structured address parts and coordinates, one property by its UPRN with its use class and registered leases including years remaining, the title number behind a UPRN, a title's address, type, ownership and lease information, local freehold titles, and an address matched to its closest UPRN.
• Valuation and sourcing: sale, rental, HMO and historical valuations with the provider's estimate, margin and confidence; investment sourcing lists such as unmodernised, repossessed, reduced, high-yield and auction properties; the national HMO register.
• Neighbourhood: crime statistics by radius, demographics, average household income, population and density, nearby schools, average council tax bills, area type, internet speeds, and property stock by type and tenure.

FAQ

What is a UK property data API used for?

Screening at a scale that manual research cannot reach. An investor runs sold prices, rents and yields across two hundred postcode districts to find where the numbers work. A lender or insurer runs flood risk, EPC and construction data across a book of addresses. A developer runs planning applications and listed building status across a search area before spending anything on a site. A proptech product puts valuations and title ownership behind its own screens. The common shape is a list of locations in and a table of facts out, which is exactly what this actor is.

How do I tell it where to look?

One location per line, in any of the four forms the provider accepts: a UK postcode (full, district or sector such as W14 9JH, W14 or W14 9), a latitude,longitude pair, a what3words address, or a town name. Each line is read by its shape unless you set the location type explicitly. Exactly one location parameter is sent per request, because the provider refuses a call that carries two and a call that carries none, and a line read as the wrong kind would be a charged answer about the wrong place.

What happens to a postcode with no data?

It becomes its own row, marked found: false, with a note explaining which of the two things happened: the provider has insufficient data for that location, or it did not recognise the input at all. Those need different fixes, so they are not collapsed into one message. A run over a hundred postcodes therefore returns a hundred rows rather than eighty-eight, and you can see at a glance which twelve were empty.

Can this actor spend money beyond the data call?

No. The provider publishes routes that buy Land Registry documents and order scale site plans, and neither is wired up anywhere in this actor. Every route it can reach is a read. That is a deliberate limit, because a scheduled run that could buy documents is a scheduled run that eventually will.

Which services return many rows and which return one?

The list services return one row per record: planning applications, listed buildings, freehold titles, UPRNs, EPC ratings, floor areas, HMO register entries, schools and sourced properties. Everything else returns one row per location or per property. The distinction matters for cost on both sides, because the provider itself charges per ten or per fifty results on the list services, and this actor prices a list row well below an area reading for the same reason.

Why is the provider's record kept whole instead of split into columns?

Because these services answer in many different shapes, and a fixed set of columns would silently drop most of what you asked for. The columns that are lifted are the ones every row has regardless of service: which service answered, which endpoint it came from, what was asked, which location parameter it was sent as, whether anything came back, and when. The provider's own record sits beside them under record, unchanged.

How long may I keep what it returns?

The provider's licence allows you to store what a call returns for up to 60 days from retrieval, then refresh or delete it, and that clock runs from the moment of retrieval rather than from the end of your subscription. Dated snapshots, derived events, your own aggregates and reports you have already produced may be kept indefinitely provided they are marked as historical and not presented as current. The rows this actor writes are ordinary dataset rows on your own account, so the retention is yours to manage: check the provider's terms before building a standing copy.

How fast will it run?

The provider rate limits per account across every key on it, between 12 and 72 requests per 30 seconds depending on plan, and the actor defaults to the slow end of that. A refusal is retried against the provider's own Retry-After header rather than a guessed delay, because a fixed backoff against a per-account limit means racing whatever else is calling the same account. Raise the requests per minute input if your plan allows and nothing else is using the key.

Why did a refusal say it was an actor bug rather than my key?

Because this provider answers an unknown endpoint and a missing key with the same HTTP 400, and only its own error code separates them: X01 for a path that does not exist, X02 for a missing key, X03 for an invalid one. The actor reads the code, so a routing mistake on its side is reported as its own fault instead of sending you off to reissue a credential that was fine all along.

Do I need my own API key?

Yes. This actor is bring-your-own-key and never ships a key of its own. Paste your key from your provider account, or set it once as the DATA_API_KEY environment secret. It travels as a request header rather than in the query string, which the provider also accepts, because a credential in a URL ends up in logs and proxy records for no benefit.

What does it cost?

Pay per result. A single property or valuation row costs the most, because one row is a complete answer about one property. A local market reading costs a little less. A list row costs well under half that, because one request commonly returns dozens. Reading your own remaining credits is priced near zero, since finding out what you have left should not itself cost anything worth counting. Platform usage is included, and locations the provider holds nothing for are never charged.

Example output

{
  "service": "soldPrices",
  "serviceLabel": "Local sold prices",
  "endpoint": "/sold-prices",
  "requested": "W14 9JH",
  "requestedAs": "postcode",
  "found": true,
  "recordType": "market",
  "retrievedAt": "2026-09-20T09:14:52.118Z",
  "record": { "...": "every field the provider published, unchanged" },
  "note": null
}

Keyword map

UK property data API, property market data API, sold prices API, asking prices API, UK rent data API, rental yield API, property valuation API UK, HMO rent data, EPC data API, energy performance certificate API, UPRN lookup API, title number lookup, Land Registry title data, freehold title search, planning applications API, listed buildings API, conservation area check, green belt check, flood risk API UK, council tax by postcode, property sourcing API, repossessed property data, auction property data, UK postcode property data, house price data by postcode, property investment data API, proptech data API, what3words property lookup.