# Data licence, attribution and personal data

> Credit the source of address data correctly under CC BY 4.0, see when addresses become personal data, and what we record about your calls.
>
> https://danadresse.dk/en/guides/licens-og-gdpr · verified 2026-11-02
Address data in Denmark is public and freely available, but the licence requires you to credit the source. And when you link an address to a person, you are processing personal data. This guide collects the practical parts: what to write, where it goes, and which data reaches us when you call the API.

This guide is not legal advice. If you are unsure about your own legal basis, ask your own adviser.

## The licence: CC BY 4.0

The addresses come from the Danish Address Register (DAR), which Klimadatastyrelsen makes available through Datafordeleren under the Creative Commons Attribution 4.0 licence (CC BY 4.0). You may use, change and pass on the data, also commercially, as long as you credit the source.

Use this text on Danish pages:

```text id=attribution-da run=no
Indeholder data fra Klimadatastyrelsen (CC BY 4.0)
```

On English pages:

```text id=attribution-en run=no
Contains data from Klimadatastyrelsen (CC BY 4.0)
```

The attribution must be somewhere people who see the data can find it. It does not have to be next to every address:

- **Websites and apps:** in the footer or on a sources page reachable from the pages where addresses are shown.
- **Address fields:** the page footer is enough. Many also add a small line below the field.
- **Exported files (CSV, Excel):** in a README, a sources sheet or a comment line at the top.
- **Your own API:** in the documentation, and preferably in a field in the response.

An example footer:

```html id=attribution-footer run=no
<footer>
  <p>Addresses: Contains data from Klimadatastyrelsen
    (<a href="https://creativecommons.org/licenses/by/4.0/">CC BY 4.0</a>).</p>
</footer>
```

The enrichment endpoints under `/api/v1/enrich/` fetch data from several registers, e.g. BBR, the cadastre (Matriklen) and property valuation. The response has a `data_source` field and often `license`, which tell you where the data comes from:

```json id=enrich-source run=no
{
  "data_source": "BBR (Bygnings- og Boligregistret)",
  "license": "CC BY 4.0 Klimadatastyrelsen"
}
```

If you show enrichment data, credit the source given in the response.

## When is an address personal data

An address on its own describes a place. It does not point to a particular person. When you store the address with a name, a customer number, an email or a phone number, it becomes information about that person, and then it is personal data under the GDPR. You are responsible for that processing.

For most integrations this means:

- Your customer database with names and addresses is personal data. Validating the address against a public register does not change that.
- A list of every address in a postcode, with no people attached, is not.
- An address id from us (`id` or `adgangsadresseid`) identifies a place. Stored on a customer it becomes part of that customer's data.

## Send only the address to us

The API only needs the address. Names, emails, phone numbers and CPR numbers do not belong in a call, and it is easier for you if they never leave your system. When you clean a customer record, send only the address fields:

```python id=minimise run=live expect="kategori"
import os

import requests

customer = {
    "name": "Jens Hansen",
    "email": "jens@example.dk",
    "phone": "+45 12 34 56 78",
    "address": "Strandvejen 100, 2900 Hellerup",
}

# Only the address leaves your system
r = requests.get(
    "https://api.danadresse.dk/datavask/adresser",
    params={"betegnelse": customer["address"]},
    headers={"X-Api-Key": os.environ["DANADRESSE_API_KEY"]},
    timeout=10,
)
r.raise_for_status()
wash = r.json()
print("kategori:", wash["kategori"])
if wash["resultater"]:
    customer["address_id"] = wash["resultater"][0]["adresse"]["id"]
    print("address id stored on the customer:", customer["address_id"])
```

If the address field contains a c/o line or a company name, remove it before you send the text.

Send the key in the `X-Api-Key` header rather than in the URL. URLs easily end up in logs on your side, in proxies and with us.

## What we record about your calls

The full description and the retention periods are in the [privacy policy](/en/privacy). In short:

- **Usage:** the number of calls per key, day and channel (API or MCP). It is used for quotas and invoicing. According to the policy, call logs are kept for 30 days and then aggregated per month.
- **Key control:** how many different IP addresses each live key is used from per day, so we can detect leaked keys. See [Rotate API keys](/en/guides/roter-noegler).
- **Security:** requests that look like attacks or scanning are recorded with IP address, path, method and user agent for up to 90 days.
- **Statistics about our websites:** counted in aggregate without storing IP addresses and without cookies.

According to the policy, all servers run in the EU.

## Data processing agreement

Our terms say a data processing agreement (DPA) is available for Enterprise customers on request. Write to us via [support](/en/support) or at hello@lynbro.dk if you need one, or if you have questions about how we process data. The terms are at [/en/terms](/en/terms).

## Next steps

- Clean addresses without sending personal data: [Datavask in checkout](/en/guides/datavask-i-checkout).
- Keep the key out of URLs and logs: [Rotate API keys](/en/guides/roter-noegler).
- Ready for production: [Go-live checklist](/en/guides/go-live-tjekliste).