What is Brønnøysundregistrene?

What kind of institution is Brønnøysundregistrene?

A government agency whose job is to keep Norway's authoritative records about legal entities: which ones exist, what form they take, who holds which roles in them, and what they have filed. The name comes from the town where it sits, and the plural is deliberate: it is one authority running several registers, not one database with several views.

Entities enter the system through a single channel. A new company files a Samordnet registermelding, the coordinated register notification, through Altinn, and that one filing feeds the relevant registers. From then on the registers evolve on their own rhythms: the entity record changes when the company reports a change, the accounts register changes when a new årsregnskap is filed. What binds them together is the organisation number, which acts as the join key across everything the authority publishes.

Which registers does a developer actually meet?

Three, in practice. Enhetsregisteret is the base register: every registered entity appears there with its 9-digit organisation number, its organisational form such as AS or ENK, and its role holders. Foretaksregisteret is the Register of Business Enterprises, which commercial companies must register in for legal corporate status and name protection, and it is where the registered signaturrett and prokura texts live. Regnskapsregisteret is the accounts register, holding each company's filed annual accounts as public documents.

The authority runs further special registers beyond these three, but most integrations never touch them. What matters is the modelling consequence: a question about a Norwegian company is really a question addressed to one specific register, and knowing which one decides what an honest answer can contain.

What data is public, and under what licence?

The company core data is open and published under NLOD, the Norwegian licence for open public data, which permits reuse including in commercial products. Filed annual accounts are public as well: anyone can read what a Norwegian company filed, which is unusual by international standards and shapes what a verification check can honestly promise.

Open does not mean uniform. The signing authority texts sit on the Foretaksregisteret tier and are not exposed in the open role feed, so an open-tier answer about signaturrett or prokura is honestly "unknown", never an empty list, a distinction the guide on company roles in the register walks through in detail. Absence from a feed is not evidence of absence from the register, and systems that conflate the two report a false negative about who may sign.

Is it the Norwegian Companies House?

Structurally, yes: it is the closest analogue to Companies House in the UK or a state registrar in the US, the national authority where companies are registered, filings land, and the public record of corporate existence lives. If you know how to reason about a registrar in those systems, most of that intuition transfers.

Two differences change how you build. First, the namespace is national and singular: one 9-digit organisation number per entity, carrying a MOD-11 control digit, with no per-state registration to reconcile. Second, the default is openness: the core record is licensed for reuse rather than sold per lookup, so the barrier to entry is engineering effort, not a data contract.

How do developers access it?

The registry exposes an open REST surface at data.brreg.no, and the open tier needs no credential at all. That path hands you raw registry payloads with registry field names, which you map into your own model, cache responsibly and re-map when they change. The registry publishes updates continuously as filings are processed, but a raw payload does not state how fresh any given field is, so freshness tracking and change detection become your code.

The alternative is a normalised layer that does that work once. Apier answers the same open facts as one stable company object with freshness and source stated on every response, and the guide on accessing register data through a REST API owns that story end to end. If you are starting from a company name rather than a number, the organisation number lookup guide covers resolving one before any other call.

Make the first call

The sandbox call below returns a simulated company's summary with no key at all, so you can see the normalised shape before signing up for anything. The TypeScript sample reads a real company's summary with an API key: entity type, VAT registration, obligations and deadlines, with freshness stated in the response itself.

# Zero-auth sandbox: a simulated company's summary, no key needed.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/summary

// One normalised read: entity type, VAT status, obligations and
// deadlines for a real company, with freshness stated on the response.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/summary",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

if (!res.ok) {
  // Every non-2xx answers the same structured envelope.
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data, _meta } = await res.json();
console.log(data.entity_type, data.mva_registered, data.deadlines.length);
// The _meta block states where the answer came from and how fresh it is.
console.log(_meta.data_freshness, _meta.served_from);

Frequently asked questions

Is Brønnøysundregistrene data free?

The company core data is open and published under NLOD, the Norwegian licence for public data, which permits reuse including in commercial products. There is no credential to obtain and no data licence to negotiate for the open tier, and filed annual accounts are public too. The cost sits elsewhere: normalising registry field names, caching responsibly, tracking freshness and detecting changes are engineering work whether you do it yourself or read the same facts through a normalised API layer.

What is the difference between Enhetsregisteret and Foretaksregisteret?

Enhetsregisteret is the base register: every registered entity appears there with its organisation number, organisational form and role holders, whatever kind of entity it is. Foretaksregisteret is the business register on top of it, which commercial companies must register in for legal corporate status and name protection, and it carries the registered texts on signing authority, the signaturrett and prokura provisions. A company can exist in the first without appearing in the second.

Is Brønnøysundregistrene the Norwegian Companies House?

It is the closest analogue: the national authority where companies are registered, filings land and the public record lives, the role Companies House plays in the UK and a state registrar plays in the US. Two structural differences matter to integrators. Norway has a single national namespace, one 9-digit organisation number per entity with no per-state registration, and the core data is open by default under a standard licence rather than sold per lookup.

Can I get the data as an API?

Yes, in two shapes. The registry itself exposes an open REST surface at data.brreg.no, where the open tier needs no credential at all. That gives you raw registry payloads with registry field names, which you normalise, cache and re-map yourself. The alternative is a normalised layer such as Apier, which answers the same open facts as one stable company object and states data freshness and source on every response, so cached and live reads are distinguishable.

How fresh is the open data?

The registry publishes updates continuously as filings are processed, but a raw payload does not tell you when the fields you are reading last moved, so freshness becomes something you track yourself per fetch. A consumer layer can state it per response instead: every Apier answer carries a _meta block with data_freshness and served_from, so a cached read is distinguishable from a live fetch on the response itself, without any assumed latency numbers.