BAG API: Individuele Bevragingen, extract and OGC API

The Basisregistratie Adressen en Gebouwen (BAG) is the Dutch key register of addresses and buildings. A basisregistratie is a legally designated national register that is the single authoritative source for one kind of data; Dutch government bodies must use it instead of keeping their own copies. Its licence is the Creative Commons Public Domain Mark 1.0. The BAG contains addresses, buildings (panden), accommodation units (verblijfsobjecten), berths for boats, pitches for caravans and towns. The Kadaster, the Dutch land registry, runs the national facility (LV-BAG) and delivers several products from it. The choice depends on three questions. How many objects do you need, how current must the data be and are you willing to request a key first?

The licence is the same for all routes: the Kadaster writes that BAG data is open data and that the Creative Commons Public Domain Mark 1.0 applies. How that relates to other licences is covered on the page about open data licences (in Dutch).

This API is free but not anonymous. You request an API key with the Kadaster's form and send it in the header X-Api-Key. The OpenAPI description (version 2.9.2) gives https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2 as the base URL. The Kadaster offers no separate test environment; testing happens on production.

Without a key the service answers on 11 October 2026 with status 401 and the text "Missing API Key". The OpenAPI description gives status 403 for an invalid key and also describes 429 for exceeding the limit.

De API is expliciet niet bedoeld voor bulkbevragingen waarmee veel gegevens in 1 keer worden opgevraagd en in een database worden verwerkt.

Source: Kadaster, Richtlijnen voor het gebruik van de BAG API Individuele Bevragingen (Dutch original; in English: "The API is explicitly not intended for bulk queries that request a lot of data at once and process it into a database").

The example below was not run by us, because TechinFlow has not used a key for this API. The parameter names come from the Kadaster's OpenAPI description. The /adressen endpoint supports searching by postcode and house number, by town, street and house number, or by the identifier of an addressable object or building.

curl -s -G "https://api.bag.kadaster.nl/lvbag/individuelebevragingen/v2/adressen" \
  -H "X-Api-Key: $BAG_API_KEY" \
  --data-urlencode "woonplaatsNaam=Amersfoort" \
  --data-urlencode "openbareRuimteNaam=Stationsplein" \
  --data-urlencode "huisnummer=12" \
  --data-urlencode "exacteMatch=true"

The answer is a HAL collection with the addresses under _embedded.adressen. According to the schema, an address contains openbareRuimteNaam (street name), huisnummer (house number), postcode, woonplaatsNaam (town), nummeraanduidingIdentificatie, adresseerbaarObjectIdentificatie and pandIdentificaties, among others. With expand you fetch the related objects in one call.

Put the key in an environment variable or a secrets manager and call the API from your server. A key in browser code is readable by anyone. How to set up such an integration is covered under API integrations (in Dutch).

PDOK's BAG OGC API asks for no key. The collections on 11 October 2026 are adres, ligplaats (berth), pand (building), standplaats (pitch), verblijfsobject (accommodation unit) and woonplaats (town). The example below converts an address to BAG identifiers through the Locatieserver (see PDOK Locatieserver and Location API) and then fetches the accommodation unit and the building. It was run with Node 24 on 11 and 12 October 2026 with the same output.

const LS = 'https://api.pdok.nl/bzk/locatieserver/search/v3_1/free';
const BAG = 'https://api.pdok.nl/kadaster/bag/ogc/v2';

async function json(url) {
  const res = await fetch(url);
  if (!res.ok) throw new Error(`${res.status} for ${url}`);
  return res.json();
}

// 1. address to BAG identifiers (Locatieserver)
const q = new URLSearchParams({ q: 'Stationsplein 12 Amersfoort', fq: 'type:adres', fl: 'adresseerbaarobject_id', rows: '1' });
const { response } = await json(`${LS}?${q}`);
const vboId = response.docs[0].adresseerbaarobject_id;

// 2. accommodation unit from the BAG OGC API, filtered on identifier
const vbo = (await json(`${BAG}/collections/verblijfsobject/items?f=json&identificatie=${vboId}`)).features[0];
console.log(vbo.properties.status, '-', vbo.properties.oppervlakte, 'm2 -', vbo.properties.gebruiksdoel);

// 3. the building through the href in the response
const pand = await json(vbo.properties['pand.href'][0] + '?f=json');
console.log('pand', pand.properties.identificatie, 'bouwjaar', pand.properties.bouwjaar, pand.properties.status);

Output (the values are Dutch: "in gebruik" means "in use", "bouwjaar" is year of construction):

Verblijfsobject in gebruik - 8 m2 - overige gebruiksfunctie
pand 0307100000595635 bouwjaar 2024 Pand in gebruik

The accommodation unit has the identifier 0307010000595643 and a property pand.href with the URL of the building it belongs to. This keeps every response small and lets you navigate the relations yourself.

For a map selection you use the parameter bbox. By default it is in WGS84. With bbox-crs you specify RD, and with crs you request the response in RD. The collection supports CRS84, RD (EPSG:28992), Web Mercator and ETRS89 (EPSG:4258), with RD as the storage system.

curl -s -G "https://api.pdok.nl/kadaster/bag/ogc/v2/collections/pand/items" \
  -d f=json -d limit=5 \
  --data-urlencode "bbox=154150,462680,154250,462760" \
  --data-urlencode "bbox-crs=http://www.opengis.net/def/crs/EPSG/0/28992"

On 11 October 2026 this returned five buildings, including 0307100000308303 and 0307100000311531. According to the OpenAPI description, the parameter limit has a default of 10 and a maximum of 1,000. For more results you follow the link with rel="next", which contains a cursor.

The queryables of the collections pand and adres consist only of geometry and identificatie. Filtering on street name or construction year in the API itself therefore does not work. A CQL filter on woonplaats_naam returned status 400. So first look up an identifier through the Locatieserver, or select spatially and filter in your own code. An address search form is thus not something you build directly on the OGC API.

• The postcode is missing in the accommodation unit. The accommodation unit for Stationsplein 12 returned postcode: null. The postcode belongs to the address designation (nummeraanduiding); fetch it through the collection adres or through the BAG API.
• The 2024 building is not everywhere. The building at Stationsplein 12 has construction year 2024 and was in the BAG OGC API on 11 October 2026, but not in the 3D BAG. Every derived dataset lags behind at its own pace.
• PDOK does not show all addresses. The PDOK description reports that the services include only the main address. Objects with secondary addresses are then incomplete. The Kadaster says the same for the BAG GeoPackage, which holds at most one building per accommodation unit and one address per addressable object.
• Historical errors remain visible. The history model keeps all occurrences. In the BAG Extract you will therefore also find old errors, unless you filter on current occurrences.
• Wrong route for bulk. If you need the whole BAG and 50,000 requests a day will not do, choose the Extract or the GeoPackage. See also PDOK fair use and caching (in Dutch).

The BAG contains addresses and buildings, not cadastral parcels; those belong to the BRK and cadastral map. For the outlines of roads, water and green space at large scale use the BGT. For building height you need the 3D BAG. For statistics per neighbourhood use CBS Wijken en Buurten (in Dutch).

You can check a BAG address without code with the BAG address check (in Dutch). If you want to show BAG data alongside your own data, a GIS viewer for municipalities is the usual route. You report an incorrect address to the source holder; the process is described under reporting errors to key registers (in Dutch). The overview of all datasets is on the hub Dutch open data.