Skip to content
Apier.no
Guides

How to get every check on a Norwegian company in one call

Call GET /api/v1/company/{org}/checks to get registration status, bankruptcy and liquidation flags, VAT, roles, coded signing authority, annual accounts and requirements evidence, each with its own status, source and freshness, and no verdict.

[Cite this as: Apier.no Docs v0.1.0 — last updated 2026-10-30]

The check bundle returns every relevant check on one Norwegian company in a single call. Each check is listed in a fixed order and carries its own status, the fact as Apier read it, the source, the source URL, when it was read, how fresh it is and the licence it was obtained under.

The bundle is a list of facts. It never gives a verdict: there is no summary field, no overall status and no count of checks. You decide what the facts mean for your use.

CheckWhat it reads
registration_statusThe company's status in Enhetsregisteret.
bankruptcy_liquidationThe bankruptcy, liquidation and forced liquidation flags.
vat_registrationWhether the company is registered in the VAT register.
rolesHow many signaturrett and prokura holders are registered (no names).
coded_signing_authorityThe coded state of the signature and prokura rules.
annual_accounts_filedWhether annual accounts are on file, and the latest year.
requirements_evidenceWhich facts to check for the requirements that apply to the company's type today.

Step 1 — Call the endpoint

curl -H "Authorization: Bearer $APIER_API_KEY" \
  https://www.apier.no/api/v1/company/{org}/checks

Replace {org} with the company's 9-digit organisasjonsnummer. The fixture 999999999 exists only in the sandbox (Step 5), so production does not resolve it.

The key needs the read:brreg scope. The call is billed as one company read.

Step 2 — Read the status of each check

Every entry has a check_status with one of five values:

StatusMeaning
verifiedThe source answered and the fact is on record. An adverse fact, such as a bankruptcy flag, is still a verified fact.
missingThe source answered and the fact is not on record.
staleThe fact is on record but older than the source's freshness window.
unavailableThe source could not be read on this call. This is never a failed check.
not_checkedNothing was evaluated for this check.

Read the value of each entry for the fact itself, and freshness for how recent it is: served_from, max_age_days and stale.

Step 3 — Handle a source that is down

When a source cannot be read, its own checks answer unavailable and the call still returns 200 with every other check filled in. Retry later for the unavailable checks; do not read them as a negative answer.

When every check is unavailable or not_checked, nothing was evaluated and the call is not charged: _meta.cost_nok is 0.

Step 4 — Ask for a signed copy

Add ?certificate=true to get the bundle wrapped in a signed certificate that you can verify offline against /.well-known/jwks.json, the same way as described in How to verify an apier certificate.

curl -H "Authorization: Bearer $APIER_API_KEY" \
  "https://www.apier.no/api/v1/company/{org}/checks?certificate=true"

Historical dates are not available yet: ?as_of= is refused with 400 VALIDATION_FAILED, and so is any other unknown query parameter.

Step 5 — Try it in the sandbox

GET /api/v1/sandbox/company/{org}/checks returns the same bundle over synthetic fixtures with a sandbox bearer, and is never charged. In the sandbox the coded signing authority and the requirements evidence answer not_checked, because those checks read stores the sandbox does not use.

From an MCP client, call get_company_verification with mode: "checks".

Building with an LLM? Read llms.txt for agent-oriented integration guidance.