Address replication in Denmark — mirror DAR locally

Most applications call an address API at runtime — the user types, the API responds, done. But some systems need all Danish addresses available locally: offline apps, data warehouses, high-throughput pipelines that cannot afford round-trip latency on every record. That is what address replication is for. This guide explains how the DAWA replication protocol works and how to keep a local mirror in sync after DAWA closes on 17 August 2026.

What is address replication?

Address replication means maintaining a local copy of the full Danish address dataset — all 2.7 million addresses and 1.1 million access addresses from DAR — and keeping it up to date as addresses are created, changed and deleted.

DAWA provided a replication protocol based on an event stream: every change to an address in DAR produces a numbered event. A subscriber keeps track of the last event it processed (the sequence number) and periodically fetches new events to apply to its local copy.

Danadresse exposes the same replication protocol, with the same sequence numbers from DAR. If you already have a DAWA replication subscriber, migration is a URL change.

When do you need replication?

Most applications do not need replication. You need it when:

• Offline functionality — your app works without network connectivity (field apps, offline-first mobile apps, embedded systems).
• High lookup volume with low latency — you do millions of address lookups per day and round-trip API latency matters at scale.
• Data warehouse / data lake integration — you join Danish addresses with other datasets in your own database or analytical platform.
• Compliance and audit — you need a timestamped log of every address change for regulatory purposes.
• Address enrichment pipeline — you pre-enrich addresses with BBR/valuation/energy data and cache the results locally.

If you are just building address autocomplete or validating an address at checkout, you do not need replication. The hosted API handles that.

How the event stream works

The replication protocol has two endpoints:

senesteSekvensnummer — latest sequence number

GET /replikering/senesteSekvensnummer
→ { "sekvensnummer": 987654 }

Call this to find the latest sequence number. Use it to detect whether new events are available (compare to your stored "last processed" number).

haendelser — event stream

GET /replikering/haendelser?sekvensnummerfra=12345&maxantal=1000
→ [
    { "sekvensnummer": 12345, "operation": "Update", "tidspunkt": "2026-06-01T14:32:00Z",
      "entitet": "Adresse", "data": { "id": "0a3f50c8-...", "vejnavn": "..." } },
    ...
  ]

Fetch events starting from a given sequence number. maxantal limits the batch size (max 10,000). Events have three operations: Insert, Update, Delete.

Entity types include: Adresse, Adgangsadresse, Postnummer, Vejstykke, NavngivenVej, Kommune, Region, Sogn.

Initial load — bootstrapping your local copy

On first run, you cannot start from sequence number 1 and replay every event ever — there are hundreds of millions of historical events. Instead, bootstrap with a snapshot:

1. Note the current senesteSekvensnummer (call it N).
2. Download the full address dataset snapshot (available as CSV/JSON via /adresser?format=csv&srid=&side=1&per_side=10000 — paginate through all records).
3. Import the snapshot into your local database.
4. Start your event loop from sequence number N+1.

This ensures you don't miss any events that arrive during the snapshot download.

The polling loop

A minimal replication subscriber in pseudocode:

last_seq = load_from_db("last_processed_sequence")

while True:
    latest = GET /replikering/senesteSekvensnummer
    if latest > last_seq:
        events = GET /replikering/haendelser
                      ?sekvensnummerfra={last_seq + 1}
                      &maxantal=1000
        for event in events:
            apply_event(event)  # Insert/Update/Delete in local DB
            last_seq = event["sekvensnummer"]
        save_to_db("last_processed_sequence", last_seq)
    sleep(60)  # poll every minute

Important: persist last_seq durably (database, not memory) so a restart does not replay events or miss them.

Migrating a DAWA replication subscriber

If you have an existing DAWA replication subscriber, migration is straightforward:

1. Change the base URL: https://api.dataforsyningen.dk → https://api.danadresse.dk
2. Add the API key header: X-Api-Key: dawa_live_…
3. Your sequence number is valid. Danadresse uses the same DAR sequence numbers as DAWA. Your subscriber continues from exactly where it left off.

No re-bootstrapping, no re-download of the full dataset, no schema changes.

Replication is an Enterprise feature

Danadresse's replication API is part of the Enterprise tier. This ensures reliable infrastructure (dedicated capacity, SLA, priority support) for the use cases that need it — offline systems, data warehouses and compliance pipelines are business-critical and deserve guaranteed availability.

If you are currently using DAWA replication in production, contact us to discuss an Enterprise migration. We offer onboarding support for large-scale replication subscribers.