From an address to a trusted property record

{
  "address": "8 Wall Street, Blackpool",
  "postcode": "FY1 2EG"
}

One call resolves the address and returns the property behind it. The response leads with the match decision, then the attributes.

{
  "match_status": "MATCHED",
  "match_confidence": "HIGH",
  "score": 1.0,
  "uprn": "100010837358",
  "matched_address": "8 Wall Street, Blackpool",
  "address_source": "ADDRESS_MASTER",

  "property_type": "Terraced",
  "bedrooms": 2,
  "total_floor_area": 53,
  "source": {
    "property_type": "price_paid",   // Land Registry
    "bedrooms": "Portal",            // listing data
    "total_floor_area": "EPC"      // survey-derived
  },
  "council_tax": {
    "band": "A",
    "authority": "Blackpool",
    "amount": 1675.48,
    "year": "2026"
  },
  "epc": {
    "rating": "C",
    "main_fuel": "mains gas (not community)",
    "fuel_category": "MAINS_GAS",
    "lodgement_date": "2026-02-12"
  }
}

A live production response, abridged. Full field reference in the developer documentation.

Two details in that payload matter more than the attribute count.

The first is source. Every core attribute says which dataset it came from, because a bedroom count from a portal listing and a floor area from a lodged EPC are not the same kind of fact and should not be treated as one. A consuming system can apply its own trust rules instead of inheriting ours.

The second is fuel_category. The raw certificate strings differ between England, Wales and Scotland — "mains gas (not community)" against "Gas: mains gas" — and both normalise to the same category. Normalisation like this is unglamorous and it is most of the work.

A lower match rate can be the right answer. Home addresses resolve almost completely, even when they have been typed by hand. Planning sites are a different thing: an application for “land to the rear of No. 4” describes a piece of land, not a property, and it has no UPRN of its own. Refusing to return one is correct; returning the nearest house would be wrong, and it would look like a perfectly good answer.

A match has to name the property that was asked for. Across nearly 19,000 matches, every flagged result was checked by hand, and none returned a different building.

Rural sets match less often than urban ones. Our reading is that this is mostly the input mix — rural samples contain far more planning sites and land titles — but that is an inference rather than something the test isolates.

Scotland is lower than England, and part of the reason is how Scottish addresses are written. Flats are recorded by floor and position, and the registers disagree on the separator: FLAT 2-1 1083 TOLLCROSS ROAD GLASGOW in one source is Flat 2/1, 1083 Tollcross Road in another. Every one of these cases in the test was matched correctly, where a plain string comparison would have missed them all. We would rather publish the gap that remains than average it away.

Speed matters as much as rate in an onboarding flow: a lookup typically takes a little over 100 ms per address, and under a second and a half at the 95th percentile.

Two things are worth drawing out. Fill rates are field-specific, which is why an API has to handle nulls honestly rather than substituting a plausible default. And council tax amount — the annual charge, not just the band — is returned for around 86% of matched properties. Holding the charge means holding a rate for every band in every billing authority for the current charging year, which is a materially harder thing to maintain than the band alone.

Have an address file you need to resolve or enrich? PDI supports real-time API, bulk matching and bespoke data-feed workflows. See the API or talk to us about a bulk run.