Since January 2026, there has been a significant change in the world of BAG data: the Land Registry has launched a new API called BAG OGC API Features. This API offers a more modern way to retrieve data from the Basic Register of Addresses and Buildings and has been developed in accordance with international OGC standards. As such, it is not merely a technical add-on, but truly a new gateway to BAG information—one that is particularly interesting for developers, geo-specialists, and anyone working with large-scale address and building data.
Although the new API is not intended as a direct replacement for the existing BAG API Individual Queries, it does offer a much more accessible alternative—especially for those who want to retrieve larger amounts of data or who want to get started without immediately requesting API keys.
The BAG OGC API Features is based on the OGC API – Features standard, an international framework designed to make geographic object data accessible via web services. In practice, this means that you can retrieve BAG objects such as:
The API supports modern formats such as JSON and GeoJSON, allowing you to use the data directly in web applications or GIS software. Furthermore, the API is fully RESTful, which makes integration into modern applications easy.
A major advantage: you no longer need an API key. This means you can get started right away, without any application procedures or limits on the number of requests you can make per day.
With this new API, you can query BAG objects using various filters. For example, you can retrieve all residential properties in a specific municipality or query buildings with a particular status. The API’s structure also makes it easy to paginate results, which is useful if you expect large numbers of responses.
Imagine you’re working on an application that displays a map layer with current property data in a municipality. With a simple API call, you can retrieve all this data at once—without limits, without a key, and in a format that fits directly into your map view. That’s a clear improvement over previous methods.
Until recently, users relied on the BAG API Individual Queries for this type of application. This API essentially still does exactly what its name implies: it allows you to retrieve individual BAG objects, but always based on a specific BAG ID, such as a residence object ID or a number designation ID.
That API works fine, but it did have some drawbacks. For example, you always had to request an API key before you could even get started, and there was a limit on the number of queries per day. This worked fine for simple applications, but for projects that wanted to retrieve or integrate larger amounts of data, it quickly became cumbersome.
Furthermore, the old API does not comply with modern standards such as OGC, which could make its use in combination with other (international) geoservices more difficult.
The Individual Queries API is still available at this time, but it is quite possible that it will be phased out in the future. No official announcement has been made yet, but given the direction Kadaster and PDOK are taking with OGC APIs, it is not inconceivable that this older API will eventually disappear.
The overview below shows how the new API compares to the older one. This is not a matter of right or wrong, but simply a matter of differences in design and capabilities:
| Feature | BAG API Individual Queries | BAG OGC API Features |
|---|---|---|
| Requires API key? | ✅ Yes | ❌ No |
| Query limit? | ✅ Yes | ❌ No |
| Does it support JSON / GeoJSON? | ❌ Limited | ✅ Fully |
| Based on the OGC standard? | ❌ No | ✅ Yes |
| Bulk queries possible? | ❌ Only per object | ✅ Yes, via filters & pagination |
| Can I search by address? | ❌ No | ❌ Still not |
As you can see, there are clear technical improvements in the new OGC API. However, the existing API will remain usable for the time being for applications that are already running on the old structure.
Although the new API is a significant step forward, it does have some limitations. The most important one is that you still cannot search directly by address. Just like with the old API, you need to have the BAG ID of the object you want to query. You cannot derive such an ID from an address using this API itself.
For example, if you want to know the BAG information for the address “Herenstraat 1, Utrecht,” you’ll first need to use the PDOK Location Server to find the correct BAG-ID based on that address. Only then can you use that information in the OGC API Features to query the relevant object.
This applies to both the old and the new API: looking up an address is a separate step that falls outside the scope of the APIs themselves.
The BAG OGC API Features is particularly useful for developers and geospatial specialists who want to work with up-to-date BAG data without any technical barriers. Since an API key is no longer required and queries can be easily executed, the API is ideal for:
At the same time, the older Individual Queries API remains usable for applications where a very specific object needs to be queried, for example based on previously saved BAG IDs. However, please note that this API may eventually be phased out—though nothing definitive has been announced at this time.
The introduction of the BAG OGC API Features demonstrates that working with BAG data is increasingly shifting toward open standards, scalability, and modern integrations. For organizations that work with address and building data, this means that the technical choices made today will impact the future-proofing of systems and processes.
Are you already working with BAG data? Then now is the time to assess whether your current approach aligns with the new OGC standard. Are you exploring a role in BAG management or geoinformation? Then knowledge of these developments is essential.
Want to learn more about the responsibilities and day-to-day work of a BAG manager? Or would you like to learn how to work with BAG data and APIs in a practical way through Geo-ICT’s BAG course?
This way, you’ll ensure that you not only understand the technical changes but also know how to respond to them professionally.
