National Land and Property Gazetteer API development

Full Application: Not funded at this stage

Problem: councils struggle to implement modern APIs for local address lookup which resolve unique property reference numbers (UPRNs), so where digital services are developed by or in collaboration with third parties, those solutions must rely on expensive, closed NLPG APIs that offer poor usability for end users and/or frustrating onboarding process for software developers.

Objective: free and open, cloud-friendly NLPG APIs to support digital services with first-class usability for citizens and frictionless onboarding for software developers.

Ordnance Survey distribute NLPG data via the AddressBase Premium product. To be useful in web sites and apps, this data must be loaded into databases by each council or their suppliers on a six-week cycle. This process is duplicated

GDS developed software for loading this (and related Codepoint) data into a database and exposing it as an API. This code was contributed publicly on Github under an MIT license.

The software components of this solution are:

Locate API:

Location Data Importer:

Locate API front end:

A solution utilising these components is now hosted by Surrey Digital Services for other councils to use. To date, 22 councils are using this solution.

Whilst the basic functionality provided by the API (enumerating addresses by full postcode) is useful, the service cannot support the user experience provided by the likes of the Google Places API, such as search by partial address and type-ahead completion. This is particularly problematic for service users who do not know their postcode, such as vulnerable people in temporary accommodation.

The proposal is to extend the Locate API with additional functionality to support these use cases, and make the results available to all UK councils (and their authorised IT service providers) who are licensed to use this data via their PSMA membership, for integration with a range of digital services.

Essential events or milestones

  1. Consultation with existing users of the Surrey Digital Services addressing solution, including both the API and supporting components (location data importer and API frontend). Deliverable: a written report.
  2. Hosting of a clone of the Surrey Digital Services solution on Amazon Web Services. Deliverable: a working cloud-hosted API with existing features.
  3. Implementation of new addressing service endpoints. Deliverable: a working API with new features.
  4. Implementation of reference implementations demonstrating how this improved API can be used in public-facing digital services. Deliverable: reference implementation(s).
  5. Consultation with API users to determine which additional geospatial functions could be usefully incorporated . Deliverable: written report.
  6. Engagement with wider service developer community, including third party suppliers, so establish how this work may be sustainably continued as a community effort. Deliverable: written report.

Some of these phases of work may run in parallel, for instance the engagement with the wider service developer community is expected to run throughout the project.

The current situation is that Ordnance Survey is supplied with gazetteer data by local authorities, and then after simply aggregating this data into products like Addressbase Premium puts licensing, technical and financial roadblocks in the way of suppliers of services to the same councils that originated the data. This is utterly perverse.

As a consequence, there exist a number of “value added” APIs provided by private sector organisations on top of the Ordnance Survey data which are necessarily astonishingly expensive, in order to recoup the license fees that Ordnance Survey charges these private sector organisations for “commercial” use of the data.

These expenses then get passed on to councils directly where APIs are procured directly by the councils, and indirectly through elevated costs of digital services developed by the other suppliers which consume these expensive APIs.

By building highly functional APIs fed with NLPG data acquired under existing terms from Ordnance Survey, we can eliminate the need to either use these expensive APIs, or develop alternative LLPG-based address lookup solutions.

The case for a solution of this type is demonstrated by the take up of the existing service hosted by Surrey County Council by 30 local authorities, with 22 actively engaged in use of the solution, including Surrey Heath, Elmbridge, Waverley Redbridge, Ealing; Windsor and Maidenhead, Cambridge, Oxford City, Basildon, Cambridge, Banstead, Daventry, Guildford, East Sussex, Surrey County.


The case for functional extensions to this solution is evidenced by a number of public-facing council services awaiting development by the proposed partner organisation, Looking Local, which cannot use the existing NLPG solution because of the limitations described above, most significantly the constraint that the service user knows their postcode, and the related requirement to offer users type-ahead completion of partial addresses, and for which no API is currently available for LLPG addressing.


In addition to the existing 22 councils that already use the current service, the following will directly and immediately benefit from this new service:


Barking & Dagenham





North Tyneside


South Holland

Our exposure to these needs is unlikely to be unique; they expect that services developed by Councils and third party suppliers would also benefit from these improved capabilities, and they will seek to identify such services through “re-discovery” consultation exercises in the scope of this project.

The improved APIs will be offered first to all existing users of the Surrey-hosted addressing API, and we will invite these councils to join the consultation efforts described in the Approach section of this document.

We will incorporate the new APIs into prototype services for submission of documentary evidence, and conduct user research to determine whether these improved services offer quantitatively better completion rates and transaction times, and qualitatively better user experience, than the more basic services currently offered.

Source code derived from that used in the current service will be contributed back to Github under license terms which promote further open collaboration such as direct code contributions or forking of the code into competing solutions.

Benefits/business case: from a council perspective, we expect to focus on the benefits derived from enabling third party suppliers to offer address lookup and UPRN resolution in new services without the burden on council IT or engaged suppliers to either develop and secure APIs on internal LLPG databases, or to procure (or require suppliers to procure) expensive, closed NLPG-based solutions. From an end-user perspective, we will focus on quantifying the cohort of end users who are currently unable to use postcode-based address lookups.

User research report: we will conduct two types user research reflecting the two classes of user: software developers who are direct users of the API, and members of the public who consume the resulting digital services.

Accessible product: this will take the form of a number of “reference implementations” demonstrating the integration of the new APIs with services for documentary evidence submission.

Conclusion: we believe that the technical aspects of this project are low risk, and expect that the new APIs will be incorporated into public-facing digital services within the scope of this Alpha project. It is likely that subsequent work would be focused on further streamlining the service onboarding and support processes, and developing additional reference implementations in a wider variety of software frameworks, e.g low code forms platforms. We will confirm this outcome by the last week of the project.

Whilst the fundamental rationale for this project lies in the provision of enhanced digital services to end users, the service patterns for address lookup both within local government services and within the private sector are well established.

Our proximate user base is therefore software developers. In the early stages of the project we will seek to recruit from the existing user base of the Surrey CC-hosted addressing API those developers who are particularly interested in these functional extensions. Our engagement with these users will focus on technical concerns such as their preferences for API protocols, endpoint semantics, performance, documentation, reference implementations and so on. Looking Local has considerable experience in developing APIs for third parties. In the later stages of the project we will engage with these developers to determine appetite for establishing a permanent community of users and contributors, e.g. for the development and integration of enhancements through Github pull requests.

The second class of user needs relates to the digital services consumed by members of the public. In the latter part of the project, once a prototype API and reference implementations have been developed, we will compare the user experience of postcode-oriented address lookup typically used in council-delivered digital services with partial matching type-ahead (as used, for instance, in Google Maps) and gather qualitative feedback on usability and end user preferences and quantitative feedback on address completion times.

The most useful thing that the Local Digital Collaboration Unit can provide us is the communication channels to engage with other councils and council suppliers to widen the take-up of these products and drive further discovery of related requirements.

The services built upon in this project were developed originally by GDS and extended by a Surrey partnership of the County Council, Districts and Boroughs through their GIS Forum funded by SCITO (the Surrey ICT Managers Group (local authorities)). This phase of the project is entirely new, and no external funding has been previously applied for or granted.