DAWA vs Datafordeleren — which should you use?

DAWA shuts down on 17 August 2026. The Danish government recommends migrating to Datafordeleren. But for most DAWA users, Datafordeleren requires rewriting significant parts of their integration. This comparison explains exactly where they differ — and why a DAWA analog is the simpler path for the vast majority of developers.

At a glance

Protocol: REST vs GraphQL

DAWA used a simple REST/JSON API. A Danish address autocomplete call looked like this:

GET /autocomplete?q=Rådhuspladsen&type=adresse

Datafordeleren's address data is served via GraphQL. A query for the same data looks like:

POST /graphql
{ "query": "{ DAR { Adresse(vejnavn: \"Rådhuspladsen\") { id, vejnavn, husnummertekst, postnr } } }" }

GraphQL is a powerful protocol, but it requires a GraphQL client, a different mental model, and you have to write your own search layer if you want user-typed queries to work. Datafordeleren does not have a typo-tolerant full-text search endpoint. For address autocomplete specifically, you would need to implement fuzzy matching yourself or use a search engine on top of mirrored data.

Danadresse preserves the REST interface: same URL path, same query parameters, same JSON structure.

Authentication: business agreement vs API key

DAWA required no authentication whatsoever. You called the API and it worked.

Datafordeleren requires:

1. Registering a user account
2. Requesting a tjenestebruger (service user) with access to specific services
3. For some services, signing a virksomhedsaftale (business agreement) — a multi-step process that can take days to weeks
4. Implementing OAuth2 token exchange before every API session

Danadresse requires one step: sign up at danadresse.dk/dashboard/signup and get an API key. Add it as a header: X-Api-Key: dawa_live_…. Total time: under five minutes.

Address cleansing (datavask)

DAWA's datavask endpoint was one of its most valuable features. You POSTed a free-text address string — as messy as a customer typed it — and DAWA returned the normalised DAR address with a quality category (A = exact match, B = corrected, C = ambiguous, D = no match).

Datafordeleren does not have a datavask equivalent. Address cleansing against Datafordeleren requires implementing your own text normalisation, fuzzy matching against the dataset, and quality scoring — substantial engineering work.

Danadresse has a compatible datavask endpoint: POST /datavask/adresser, same request body, same response format as DAWA, including the A–D quality categories.

When Datafordeleren IS the right choice

Datafordeleren makes sense when:

• You need raw data access — fetching entire datasets, bulk exports, or joining address data with other government registers (matrikel, BBR raw data, ownership).
• You are already on Datafordeleren for other datasets and the auth overhead is already paid.
• You are building your own search infrastructure — indexing address data into your own Elasticsearch/Typesense/Meilisearch and don't need the hosted search layer.
• Enterprise replication with SLA — Datafordeleren offers formal SLAs for data distribution.

When Danadresse is the right choice

Danadresse makes sense when:

• You are migrating from DAWA — the same endpoints mean zero code changes beyond the URL.
• You need autocomplete and datavask — hosted, typo-tolerant, ready without building a search layer.
• You need to move fast — the DAWA shutdown deadline is 17 August 2026. Setting up a Datafordeleren integration takes weeks; setting up Danadresse takes minutes.
• You want bundled property enrichment — BBR, valuation, energy label and DAGI in a single API call, without stitching together multiple Datafordeleren services.

The verdict

For the vast majority of DAWA users — webshops, CRMs, citizen portals, logistics apps — Danadresse is the migration path that preserves existing integrations. Datafordeleren is the official government channel, but it is designed for organisations that need raw data access, not for the common use case of "autocomplete in a form and return a validated address".

The two are complementary, not competing: Danadresse itself uses Datafordeleren as its data source, processes it, and serves it with the developer-friendly REST interface that DAWA established.