API Danmark: a hand-kept index of Danish public and partner APIs

A catalogue, not a library, and the distinction matters

API Danmark is a list. The repository top level makes that obvious: a `.github/` directory, a `.lycheeignore`, a `LICENSE`, the `README.md` and an `assets/` folder. There is no code, no package manifest, no build and no client library. The primary language field is recorded as unknown, which for a repository of Markdown is accurate.

What it contains is a set of tables, one per domain, and each row is an API name linking to its documentation, a format column and an availability column.

The central design decision is the availability classification, and it is explained under the heading Information. For public APIs, the note says it is free to use, also when it requires a login. For private ones, you need a relation to the company publishing the API, paid or not.

That single column is the most useful thing in the catalogue, and it is the thing a developer building in Denmark discovers the hard way. A public API in the Danish public sector sense often still needs a login, and a private one may still be free, but it requires a commercial relationship with the vendor. Neither of those is obvious from the documentation link alone.

The opening line of the catalogue is also an instruction to contribute: if you know a Danish API that is missing from the list, send a pull request or open an issue.

The domains cover the boring parts of a Danish build

The categories are chosen by what a developer in Denmark actually needs to wire up, not by an abstract scheme.

Payments is the largest section and the one that teaches the public and private distinction best. Clearhaus, ePay, Paylike, QuickPay, OnPay, DIBS, Billwerk+, AltaPay, Scanpay, FarPay, Pensopay and Nets Netaxept are listed, with MobilePay/Vipps the single public entry among them. Almost every payment API in Denmark is private in the sense of requiring a commercial agreement, which is why the list is a guide to who to contact rather than a list of endpoints to call.

Hosting is the second largest, and it is where webshop platforms cluster: HostedShop with its Wannafind, Curanet and ScanNet services, DanDomain Webshop and DanDomain Webshop Classic, Shoporama, Simply.com, One.com for webshop and for VPS, and six separate Curanet entries for DNS, Mail, Subscriptions, Webhotel, Orders and Domains. Grouping one vendor's services under separate rows with separate Swagger links is a useful detail, because each Curanet API has its own documentation site.

Then there are the smaller and more public sections. Under COVID-19 there is the Statens Serum Institut weekly surveillance data in ZIP and CSV. Under weather there is DMI Vejr with its GeoJSON and JSON, described as weather, climate and observation data, and Vejret i din by. Under miljødata, meaning environmental data, there is the Ressource webservice for Denmark's Miljøportal. Under historie, meaning history, Dansk Kultur Arv is listed as XML and the Kalender API, a Danish calendar covering years 1 to 9999 with holidays and marked days, as JSON and public.

Detail and webshops has Salling Group as JSON. Public sector access has the System-til-system-adgang entries for CVR and Regnskabsdata, produced by Erhvervsstyrelsen, the Danish Business Authority.

Reading the table is reading the decision you have to make

Each row carries three pieces of information and the third is the one that changes your plan.

The format column is more varied than you might expect for a list dominated by JSON. Most entries are JSON, but Nets Netaxept is XML, Dansk Kultur Arv is XML, HostedShop is SOAP, the Statens Serum Institut data is ZIP and CSV, and DMI Vejr is GeoJSON and JSON.

That spread is a useful signal about the Danish API scene in one glance. JSON is the default for anything commercial, but the older institutional and payment infrastructure is XML or SOAP, and the bulk data releases from public bodies arrive as archive files rather than HTTP APIs. If you are integrating with the Danish state or with a payment provider, you will be handling XML or a downloaded file at some point, and the table tells you that before you design the client.

The accessibility column then decides the timeline. A public row with a ZIP file means you can fetch data now. A private payment row means you are starting a commercial negotiation. A public row with a login means you can start immediately, but you need to register.

The documentation links themselves are the vendor's own pages, mostly with Swagger interfaces, which means the entries point at machine readable specs in the XML and JSON cases and at human documentation in the rest.

How to actually use the catalogue

There is no installation step. The project is a README and a set of links, so getting the data out of it means reading it or cloning it.

The URLs the catalogue points at are the real interface. The Clearhaus entry leads to docs.gateway.clearhaus.com, the ePay entry to docs.epay.dk, and the Curanet orders entry to a Swagger page under api.curanet.dk. Each of those is a documentation site for one API, and for the JSON and Swagger based ones it is where you would start reading the request and response shapes.

For the contribution side, the workflow is stated in the first line of the catalogue: open an issue or send a pull request when a Danish API is missing. Since the whole repository is a Markdown file, a pull request is a table row.

The `.lycheeignore` file at the root is a small but telling artefact. Lychee is a link checker, and an ignore file for it means the maintainers run link checking over the table and keep a list of URLs that are known to fail and should not be treated as regressions. It also hints at the failure mode of this kind of project, which is link rot rather than wrong information.

The `assets/` directory at the root and the `.github/` directory cover the remaining infrastructure, and the LICENSE file at the repository root holds the terms, which are GPL-2.0.

What a hand-kept link list cannot tell you

Three gaps follow from the format, and they are worth naming before you rely on the catalogue.

The first is that there is no version information anywhere. A row tells you that the DIBS API exists and speaks JSON, but not which version, whether the endpoints changed, or whether the pricing and onboarding changed since the entry was written. For an integration that you are about to build, the documentation link is the only current source of truth, and you have to open it.

The second is that the list is Danish and Danish only. That is the point of the project, but it means the catalogue cannot help you decide between a Danish API and an international one, and it does not cover the cross-border options.

The third is that link rot is invisible. Entries are added by contributors, and nothing in the format records when an entry was last checked, so a link that has rotted looks exactly like one that is current. The `.lycheeignore` file helps with the entries the maintainer already knows about, but a newly rotted link stays in the table until someone notices.

There is also the scope question that the public and private classification raises but does not resolve. The catalogue tells you whether you need a commercial relationship, which is genuinely useful, but it does not tell you which provider is right for your transaction volume, what the fees look like, or which ones integrate with a specific accounting package. It is a map of what exists, and picking from the map is still your job.

Where to look instead, and what this repository is for

If you need a Danish integration today, the catalogue is a starting point rather than an answer, and it is worth pairing with the vendor documentation and with the direct contacts.

The alternative approach is to search the vendor documentation directly, which is what you will end up doing anyway for the specifics, and to use the catalogue for the part that is genuinely hard to search for: knowing which companies in a given Danish market expose an API at all. That discovery problem is exactly what a curated index solves. Payment providers in Denmark are not discoverable by searching for a generic term, and the same is true for Danish webshop platforms and for public sector system-to-system access.

The contribution model is also worth noting as a piece of the design. A catalogue of this kind only stays useful if the people who hit the missing entry can add it, and the request for pull requests or issues is the mechanism that keeps it current without the maintainer having to survey the market.

On maintenance, the repository is not archived and the last push was on 2026-10-15, with no GitHub releases, so the state of the catalogue is whatever is on the main branch. The licence is GPL-2.0, which matters if you want to reuse the list itself in your own documentation, since GPL-2.0 is a copyleft licence with obligations that differ from the permissive licences most such lists carry. This is a description of the licence terms, not legal advice, and if you intend to mirror the list you should read the LICENSE file rather than rely on the metadata.

For a developer working on a Danish product, the value is in the first ten minutes of a task, when you need to know whether an API exists at all and who to call.

Editorial conclusion

Adopt API Danmark as a starting map if you are building something against Danish infrastructure and need to know which payment, hosting, weather or public data endpoints exist and what each one speaks. Do not treat it as a reference you can rely on without checking, since it is a hand-maintained list of links with no version information, no SDK details and no status tracking, and every entry can rot silently. Verify first the access model of each endpoint you intend to use, since the public and private distinction decides whether you need a signed agreement before you can make a single request, and check the linked documentation directly rather than trusting the entry.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-2.0
3. mauran/API-Danmark on GitHub
4. README