Datafordeler, without the six things that make it hard
Datafordeler is the authoritative source for Danish property and geodata, and it is genuinely awkward to build against. Grundfast reads the same registers and re-serves them the way an application actually wants them — one token, readable values, one projection, and a cache in front so upstream downtime stays upstream.
What Grundfast takes off your plate
Each of these is a real property of the upstream API, and each one is handled before the response reaches you.
Two credentials and an IP allowlist
Datafordeler wants a web user and a service user created in a self-service portal, and several services expect the caller’s IP to be registered. Grundfast is one bearer token that works from anywhere.
Numeric code lists
A building comes back with numbers where the use, wall material, roof and heating should be. You are expected to join those against separate code list documents. Grundfast resolves them before the response leaves.
Bitemporal rows you did not ask for
Registers are bitemporal, so a naive query returns superseded versions alongside the current one. Grundfast serves current-only by default, and exposes history explicitly when you want it.
EPSG:25832 geometry
Coordinates arrive in UTM zone 32N. Every web map wants WGS84. Grundfast reprojects, so you are not shipping a projection library to the browser.
Cursors and connections
The GraphQL surface paginates with cursors and the WFS surface with start indexes. Grundfast walks both and hands you the whole result set.
Roughly 90% upstream uptime
Datafordeler goes down and flaps 401s. Grundfast retries with backoff and serves from a cache, so a bad afternoon upstream is not an outage in your checkout.
The same lookup, either way
One call on a BFE number returns the property with its buildings, units and parcels already joined.
# Datafordeler: two users, IP registration, numeric codes, UTM32 # Grundfast: one bearer token, resolved codes, WGS84 curl -H "Authorization: Bearer gf_live_..." \ "https://api.grundfast.dk/v1/bbr/ejendom/1304503"
The 2026 deadline
SDFI is retiring the old services.datafordeler.dk REST surfaces at the end of 2026 in favour of entity-based GraphQL and WFS. Integrations written against the old shape need rewriting — unless something keeps serving that shape.
That is what Grundfast is for. The convenient old form — translated codes, re-joined names, current-only, WGS84, automatic pagination — served from the new backend, so the migration is a base-URL change rather than a rewrite.
Try it against a real property
Create a free key, point your base URL at /v1, and keep the response shape your integration already expects.
See also
Frequently asked questions
Is Grundfast a replacement for Datafordeler, or a layer on top of it?
A layer on top. Grundfast reads the same official registers from Datafordeler (SDFI / Klimadatastyrelsen) and re-serves them in a shape that is easier to consume — translated code lists, re-joined names, current-only rows and WGS84 geometry. The data and its authority are still the state’s.
Why not just call Datafordeler directly?
You can, and for a one-off report that is often the right call. The friction shows up when the integration has to run unattended: two credentials, IP registration, numeric code lists, bitemporal rows, UTM coordinates, cursor pagination and an upstream that is not built for your uptime target. Grundfast absorbs all of that.
What happens to my Datafordeler integration in 2026?
SDFI is retiring the old services.datafordeler.dk REST surfaces at the end of 2026 and moving to entity-based GraphQL and WFS. Integrations written against the old shape have to be rewritten. Grundfast re-exposes the convenient old shape on top of the new backend, so the rewrite becomes a base-URL change.
Is the data licensed for commercial use?
The underlying register data originates from Datafordeler / SDFI and is CC BY 4.0. Grundfast credits the source. What Grundfast charges for is the transformation, the caching and the availability guarantee on top of the open data.