In March 2017 we opened up access to the Energy Performance of Building data via a new search tool available on Open Data Communities. Since then the data has been used extensively and widely talked about. It certainly demonstrates the value contained in Government datasets.
We’ve gathered feedback from users, and we’ve extensively tested and evaluated the best way to reliably and robustly update the dataset periodically. This will involve a change to the API and how it works and we have endeavoured to minimise the impact of this change.
What are the changes?
We’ve been able to design a solution that ensures the LMK_KEY
field in all three registers is unique, which means we can use it to identify certificates in the application and API. As a result the CERTIFICATE_HASH
(derived from the contents of the certificates) which we used to identify certificates in the initial release is no longer needed. We recognise this it isn’t ideal to change identifiers after publication, but we felt it was more important to open up the data early. Now that have a more reliable way to identify certificates, it will allow us to release more fields in the future, whilst keeping the identifiers the same. The changes will affect data already published in the following ways:
- The
LMK_KEY
will change, but once we change it it’ll be persistent CERTIFICATE_HASH
will no longer be required and will be removed as part of the change- The API for all certificate types (Domestic, Non-domestic and Display Energy Certificates) will use
LMK_KEY
to identify certificates instead ofCERTIFICATE_HASH
The Search APIs for all certificate types will continue to take the same arguments as they do now, but the results will no longer include a CERTIFICATE_HASH
field.
What impact will this have?
It really depends on how you access and use the data. It is entirely possible the changes won’t result in any adverse impact. If you have built a product or service under the terms and conditions set out on the site we advise you to evaluate any potential impact and take appropriate steps to mitigate the impact.
This is particularly important if the CERTIFICATE_HASH
is used in the product or service especially where you have stored the values locally and use them to access records via any of the 3 Certificate API’s.
When will the changes happen?
We’re working to finalise a release date and we’ll confirm when that is as soon as we can. We will update you closer to the time once the dates have been confirmed
To summarise, we’re going to remove CERTIFICATE_HASH
in favour of using a revised set of LMK_KEY
s to identify the certificates in the application, downloads and APIs.
If you have any questions you can contact us.