Is there one official API for all Norwegian public services?

No. Norway has no single official government data API. Digdir operates shared building blocks, most visibly Maskinporten for machine-to-machine tokens, but those standardise how you authenticate rather than what the data looks like. Each agency still publishes its own endpoints, its own field names and its own release schedule.

Does Maskinporten count as a unified government API?

Maskinporten is a unified front door for authentication, not for data. It issues an access token that proves which organisation is calling, and a growing number of agencies accept it. Once you hold that token you still face four different response schemas, four vocabularies for status, and four error formats.

Which sources does Apier normalise behind one key?

Brønnøysund for registry facts, Altinn 3 for forms and delegated authority, Skatteetaten for tax-side data, and NAV for employment records. They answer through one Bearer key and one response envelope, with a _meta block on every response naming the data source, the rulebook version and how fresh the data is.

Can I call the underlying registers directly instead?

Yes, and for a single open lookup that is often the right call. Brønnøysund's Enhetsregisteret is openly available under NLOD and needs no credential at all. The cost of going direct shows up when you need several agencies joined on one company, consistent freshness metadata, and a single error contract across all of them.

Do I need an API key to try a unified lookup?

Not to start. Every company endpoint has a zero-auth mirror under /api/v1/sandbox/public/ that answers the production response shape from synthetic fixtures for organisation number 999999999. Reading real company data through /api/v1/company/ requires a key, because that surface carries personal-adjacent fields such as role holders.

Is there a unified API for Norwegian public services?

No. Norway has no single official API covering public services. Each agency publishes its own surface: Altinn 3 for forms and delegated authority, Brønnøysund for registry facts, Skatteetaten for tax data, NAV for employment records, and each one carries its own credential model, its own field names and its own release cadence. Apier normalises those sources behind one Authorization: Bearer key and one response envelope, so a lookup that would otherwise mean four connectors becomes a single HTTPS call against a stable schema.

The work in a Norwegian government integration is rarely the HTTP call. It is holding four credential models and four schemas in your head at once, and keeping them correct as each agency ships changes on its own schedule.

Why doesn't Norway have one official government API?

Because each register was built for its own statutory purpose, at its own time, by the agency accountable for that purpose. Enhetsregisteret exists to answer who a legal entity is. Skatteetaten's surfaces exist to administer tax. NAV holds employment and benefit records because NAV administers those schemes. No agency has a mandate over another agency's data, so there is no owner for a merged view and no budget line for maintaining one.

Norway has gone further than most countries on the part that can be centralised, which is identity and access. Digdir operates Maskinporten as a shared machine-to-machine token service, and a wide set of agencies accept a Maskinporten token as proof of which organisation is calling. Altinn 3 adds a shared platform for forms, messaging and delegated authority. Those are real shared building blocks and they remove real work.

What they do not do is unify the data. A common token gets you through four different front doors; it does not make the four rooms behind them look alike. You still meet different field names for the same concept, different vocabularies for company status, different date formats, different pagination, and different error shapes. That gap is where integration time actually goes, and it is the gap a normalising layer exists to close.

What does a unified layer actually normalise?

Four things. Being specific matters here, because "unified" is otherwise an empty word. First, identity: the 9-digit organisasjonsnummer is the join key across every Norwegian source, so one company number resolves against all of them without a mapping table you maintain. Second, field naming and types: one company object with one set of names, rather than four objects that each spell status differently.

Third, provenance. Every response carries a _meta block naming data_source, rulebook_version, data_freshness and last_verified. That matters more than it sounds. When you merge four upstreams, the honest question about any field stops being "what is the value" and becomes "which register said so, and when". A merged response without provenance is a merged response you cannot audit.

Fourth, failure. Upstream registers fail in their own formats and at their own times, and a merged call has more ways to go wrong than a single one. Apier maps them to a structured error_code with an explanation and fix steps, identical in shape on every endpoint, and degrades explicitly rather than silently: a partially available upstream is reported as such on the response instead of being quietly dropped from the merged object.

How do I avoid building a separate connector per agency?

Start from the join key rather than the endpoint list. Almost every question a Norwegian integration asks is anchored on an organisasjonsnummer, so the first call to reach for is /api/v1/company/{org}/context, which returns the open Brønnøysund-sourced fields (name, entity type, NACE codes, status, municipality, role holders) and adds the gated commercial metrics when you hold an active delegation for that organisation. The response tells you which tier you got through data_tier, so your code branches on a field rather than on a guess.

If you hold a name and not a number, /api/v1/company/search resolves it, returning at most ten candidates with five fields each. Use it rather than constructing a number: a 9-digit value that happens to pass the checksum will resolve to some real company, just not yours. For staying current, the change archive at /api/v1/changes replaces per-agency polling with one cursor-paginated feed of detected changes, which is covered in the guide on fetching updated company data.

Build against the sandbox before you hold any credential. Every company endpoint has a zero-auth mirror under /api/v1/sandbox/public/ that answers the production response shape from synthetic fixtures, and a ?simulate_error= parameter injects the missing-delegation, invalid-token, validation and missing-scope paths so your error handling is exercised before it meets a real failure. The public mirror accepts organisation number 999999999 and rejects other numbers, which keeps it obvious that nothing on that surface is real data.

What each Norwegian government source costs you to integrate directly, against what the same data costs through one normalised call.
Source	Building it yourself	Through Apier
Brønnøysund	Open and NLOD-licensed, so access is easy. You own the normalisation, the caching, the freshness tracking and the rate-limit behaviour.	Normalised company object with provenance on the response, served from a freshness-aware cache.
Altinn 3	A Maskinporten client, an enterprise certificate, signed terms of use, a System Register entry, and a delegation from every customer.	Brokered. Your application sends one Bearer key and never handles a government token.
Skatteetaten	Scope approval per data set, its own response schema, and its own availability characteristics to design around.	Tax-side context folded into the same company object, with the source named on the response.
NAV	A separate integration with separate onboarding for employment and benefit records.	Read through the same key and the same envelope as every other source.
Staying current	A poller per agency, each with its own idea of what changed and when you may ask again.	One cursor-paginated change feed at /api/v1/changes, filterable by source and entity.

Make the first call

The sandbox request below needs nothing at all. The TypeScript snippet is the production equivalent: same path shape, one header added.

# Zero-auth sandbox: no key, no certificate, no delegation.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/context

// One call spanning several upstream registers.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/context",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

if (!res.ok) {
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data, _meta } = await res.json();
// data_tier tells you whether the gated Tier 2 block was included.
console.log(data.name, data.status, data.data_tier, _meta.data_freshness);

Frequently asked questions

Is there one official API for all Norwegian public services?: No. Norway has no single official government data API. Digdir operates shared building blocks, most visibly Maskinporten for machine-to-machine tokens, but those standardise how you authenticate rather than what the data looks like. Each agency still publishes its own endpoints, its own field names and its own release schedule.
Does Maskinporten count as a unified government API?: Maskinporten is a unified front door for authentication, not for data. It issues an access token that proves which organisation is calling, and a growing number of agencies accept it. Once you hold that token you still face four different response schemas, four vocabularies for status, and four error formats.
Which sources does Apier normalise behind one key?: Brønnøysund for registry facts, Altinn 3 for forms and delegated authority, Skatteetaten for tax-side data, and NAV for employment records. They answer through one Bearer key and one response envelope, with a _meta block on every response naming the data source, the rulebook version and how fresh the data is.
Can I call the underlying registers directly instead?: Yes, and for a single open lookup that is often the right call. Brønnøysund's Enhetsregisteret is openly available under NLOD and needs no credential at all. The cost of going direct shows up when you need several agencies joined on one company, consistent freshness metadata, and a single error contract across all of them.
Do I need an API key to try a unified lookup?: Not to start. Every company endpoint has a zero-auth mirror under /api/v1/sandbox/public/ that answers the production response shape from synthetic fixtures for organisation number 999999999. Reading real company data through /api/v1/company/ requires a key, because that surface carries personal-adjacent fields such as role holders.