Using the PDOK Location API and Locatieserver

PDOK is the platform for public geodata of the Dutch government. Since 2018 the Kadaster has operated the data portal on its own. The platform provides map layers, downloads and geocoding services, and according to PDOK itself the services are based on open data and freely available.

Two services matter for finding locations. The Locatieserver (Dutch for "location server") consists of four RESTful APIs (suggest, free, lookup and reverse) and searches addresses, parcels, roads, hectometre markers, towns, districts, neighbourhoods and water boards. The Location API is newer, follows the OGC API Common standard and returns compact results that point to the source API for the full geometry.

Most of what the two services find comes from Dutch key registers (basisregistraties), such as the BAG for addresses and the BRK for parcels.

Not completely yet. PDOK's handout says the Location API is offered "naast de huidige locatieserver" (alongside the current Locatieserver) and is "nog geen volledige vervanger" (not yet a full replacement). PDOK estimates that the first version covers about 80 percent of use cases, and still uses the Locatieserver itself in the PDOK viewer, intending to switch over.

naast de huidige locatieserver … nog geen volledige vervanger

Source: PDOK, handout Location API (Dutch; translated above: "alongside the current Locatieserver ... not yet a full replacement").

On 11 October 2026 no end date or phase-out decision for the Locatieserver could be found on pdok.nl, in the handout or in the OpenAPI description of v3_1. The v3_1 endpoints simply answered with status 200 when this page was tested.

The handout names four differences that matter in a migration:

• there is no separate suggest, free and lookup service; you fetch details with a second request to the source's OGC API Features;
• AND/OR filtering and attribute filtering besides autocomplete are missing;
• bulk download through the API does not exist yet; for much of the data PDOK offers an Atom download service;
• a few collections are still missing, such as the CBS districts and neighbourhoods (CBS is Statistics Netherlands), the Nationaal Wegenbestand (national road database) and water board boundaries.

For new applications, choose the Location API if you want to be able to point to the origin of each collection. Choose the Locatieserver if you need districts, neighbourhoods or attribute filters.

The free service is classic geocoding: you give a search text and get the best matches back. With fq=type:adres you restrict results to addresses, with fl you choose the fields and with rows the number of hits.

curl -s -G "https://api.pdok.nl/bzk/locatieserver/search/v3_1/free" \
  --data-urlencode "q=Stationsplein 12 Amersfoort" \
  --data-urlencode "fq=type:adres" \
  --data-urlencode "fl=id,weergavenaam,centroide_ll,centroide_rd" \
  --data-urlencode "rows=1"

Response on 11 October 2026, shortened to the relevant part (weergavenaam means "display name"):

{"response":{"numFound":286047,"docs":[{
  "weergavenaam":"Stationsplein 12, Amersfoort",
  "id":"adr-4f43a691bebb2eb9198d11e86db9b4fc",
  "centroide_ll":"POINT(5.37553215 52.15266021)",
  "centroide_rd":"POINT(154201.236 462720.566)"}]}}

The same call in JavaScript (Node 18 or newer, or a browser). Note the order in centroide_ll: longitude first, then latitude.

const BASE = 'https://api.pdok.nl/bzk/locatieserver/search/v3_1';

async function geocode(query) {
  const url = new URL(BASE + '/free');
  url.searchParams.set('q', query);
  url.searchParams.set('fq', 'type:adres');
  url.searchParams.set('fl', 'id,weergavenaam,centroide_ll,centroide_rd');
  url.searchParams.set('rows', '1');
  const res = await fetch(url);
  if (!res.ok) throw new Error('PDOK returned status ' + res.status);
  const { response } = await res.json();
  return response.docs[0] ?? null;
}

const hit = await geocode('Stationsplein 12 Amersfoort');
console.log(hit.weergavenaam, hit.centroide_rd);

Both services send Access-Control-Allow-Origin: *, so the call also works directly from a browser.

For a search field with autocomplete you use two steps. suggest returns short hits with an id while the user types. As soon as the user chooses, lookup fetches the wanted fields of that single object.

# step 1: suggestions
curl -s -G "https://api.pdok.nl/bzk/locatieserver/search/v3_1/suggest" \
  --data-urlencode "q=stationsplein 12 amers" \
  --data-urlencode "fq=type:adres" --data-urlencode "rows=2"

# step 2: details of the chosen hit
curl -s -G "https://api.pdok.nl/bzk/locatieserver/search/v3_1/lookup" \
  --data-urlencode "id=adr-4f43a691bebb2eb9198d11e86db9b4fc" \
  --data-urlencode "fl=weergavenaam,gemeentenaam,provincienaam,centroide_rd"

On 11 October 2026 the lookup returned, among other things, gemeentenaam: Amersfoort (municipality), provincienaam: Utrecht (province) and centroide_rd: POINT(154201.236 462720.566).

Reverse geocoding works the other way round: you give a coordinate and get the nearest objects. The service accepts RD (X and Y) or WGS84 (lat and lon), with type and optionally distance in metres.

curl -s -G "https://api.pdok.nl/bzk/locatieserver/search/v3_1/reverse" \
  --data-urlencode "X=154201" --data-urlencode "Y=462720" \
  --data-urlencode "type=adres" --data-urlencode "rows=1" \
  --data-urlencode "fl=weergavenaam,afstand"

The answer was "Stationsplein 12, Amersfoort" at a distance (afstand) of 0.61 metres. The input was rounded to whole metres, so a distance under one metre is to be expected. If you want to convert an RD point yourself, see the RD to WGS84 tool.

The Location API always asks for a collection with a version. Without that parameter the service returns status 400 with a message that you must specify at least one collection. The collection names are listed at /collections; on 11 October 2026 they included adres, gebouw (building), perceel (parcel), woonplaats (town), gemeentegebied (municipal area) and wegdeel (road section).

curl -s -G "https://api.pdok.nl/kadaster/location-api/v1/search" \
  --data-urlencode "q=Stationsplein 12 Amersfoort" \
  --data-urlencode "adres[version]=1" \
  -d limit=1 -d f=json

The result is a GeoJSON FeatureCollection. Each feature has a display_name, a highlight with the terms found, a point and an href to the full object at the source. If you want RD coordinates, add crs=http://www.opengis.net/def/crs/EPSG/0/28992; the points then come back as [154201.236, 462720.566].

const L = 'https://api.pdok.nl/kadaster/location-api/v1/search';
const u = new URL(L);
u.searchParams.set('q', 'Stationsplein 12 Amersfoort');
u.searchParams.set('adres[version]', '1');
u.searchParams.set('limit', '1');
u.searchParams.set('f', 'json');

const fc = await (await fetch(u)).json();
const feature = fc.features[0];
console.log(feature.properties.display_name, feature.geometry.coordinates);

// second request: full BAG data through the href
const detail = await (await fetch(feature.properties.href[0])).json();
console.log(detail.properties.huisnummer, detail.properties.woonplaats_naam);

That second request is the design of the service: the search result stays small and the details come from the source's OGC API Features, here the BAG. You combine several collections by passing a version per collection, for example adres[version]=1&woonplaats[version]=1.

The Locatieserver returns Solr documents with a fixed set of fields that you choose with fl. The Location API returns compact features. The table lists the fields you need most often in practice, as they came back in the tests on 11 October 2026.

The OpenAPI description of the Locatieserver sets a maximum of 100 for rows on free, with 10 as the default; suggest allows more. When free was tested with rows=500 and rows=10000, the service rejected the request with a message that the number may be at most 100. If you want more than 100 hits, page through the results with start.

A published limit on requests per second or per day is not on PDOK's pages, in the handout or in the OpenAPI description. So do not assume the service is unlimited. Build in a cache, do not fire a new lookup on every keystroke and test your expected load with PDOK beforehand, through the contact given on the site. The Location API sends Cache-Control: public, max-age=3600, no-transform; that is a hint for caching, not an agreement about limits.

Two things must be kept apart when it comes to licence. PDOK calls the services open and free. The licence of the data depends on the source register. The BAG collections in PDOK's OGC API, for example, refer in their metadata to the Public Domain Mark 1.0. For other datasets, read the licence in that dataset's metadata and record it in your own attribution.

• Coordinate order. WKT in centroide_ll writes longitude before latitude. Many map libraries expect [lon, lat] in GeoJSON, but Leaflet expects [lat, lon] for its own LatLng objects.
• The postcode is sometimes missing. For Stationsplein 12 in Amersfoort the Location API gave postcode: null, and the Locatieserver showed no postcode in the display name. Build forms that do not break on that.
• Collection and version are required. A request to the Location API without adres[version]=1 or another collection returns status 400.
• Number of hits. numFound also counts fuzzy matches. For "Stationsplein 12 Amersfoort" the service reported 286,047 hits, of which the first was the right one. So accept the first hit only when the score or the chosen suggestion justifies it.
• Spelling correction in suggest. A search without hits returns an empty docs list with a spellcheck block. Show that proposal to the user instead of an error message.
• Freshness of the data. The services lag behind the source. PDOK reports a daily update for the BAG service. If you use the address in a decision, check it with the source holder.

A geocoding service looks up a location and returns a point. It is not built for anything else.

• Loading all addresses of a municipality. Use the BAG Extract through the Atom download or the BAG OGC API, not thousands of search requests.
• Map display. Use WMTS, vector tiles or OGC API Tiles for the background map. Geocoding only returns the location.
• Complex attribute filters. If you want all buildings built before a given year in a neighbourhood, that question belongs to the OGC API Features or WFS of the dataset itself.
• Legally binding data. For a formal decision, the authentic source at the source holder is the reference.

How geocoding fits into a municipal map viewer is described under GIS viewer for municipalities; for applications built on PDOK data in general, see GIS and digital map solutions. For RD coordinates that you take from the Locatieserver, the RD to WGS84 page explains how accurate a conversion is. The overview of all datasets is at Dutch open data.