How do I perform automated Norwegian company KYC and due diligence via API?

What does Norwegian company due diligence actually require?

Start with what this page does not answer. Norway has anti-money-laundering obligations that apply to particular kinds of business, and they cover far more than looking up a company: customer risk assessment, beneficial ownership, ongoing monitoring, internal routines and reporting. Nothing here tells you whether those apply to you or whether you have met them. Treat what follows as the company-facts layer that a compliance process consumes, not as the process.

The second boundary is the word KYC itself. Verifying that a natural person is who they claim to be is a different exercise, done in Norway with an electronic ID rather than a registry lookup. This API answers questions about the company: does it exist, in what form, is it active, who is registered as able to bind it, and what has it filed. Where a person appears, they appear as a registered role holder, which is a fact about the company rather than a verified identity.

Within that scope, the practical checklist is short and each item maps to a call. Identity and form come from the company context. Whether the entity is active, bankrupt or winding up comes from the verification verdict and its underlying signals. Who may sign comes from the authority endpoint. Financial substance, to the limited extent open data provides it, comes from the annual accounts snapshot.

How do I evidence a check for an auditor?

Store what makes the check reproducible rather than what makes it look thorough. Every response carries a _meta.response_timestamp recording when it left the wire, and a _meta.response_hash, a SHA-256 over the canonicalised response body. Recording those two alongside the verdict lets you demonstrate later that the bytes your decision rested on are the bytes that were served, which a screenshot cannot do.

Send your own X-Correlation-ID on every request in the check and store it with the result. A valid UUID v4 is reused verbatim, and that identifier is persisted server-side across the audit, rule-evaluation and provenance records for the same call. When a reviewer asks what happened on a specific date for a specific customer, one identifier answers instead of a reconstruction from timestamps.

The _meta block also names data_source, last_verified and legal_basis, so the provenance of each answer travels with the answer. That matters most for the fields you did not get. A response that says the commercial tier was not included is materially different from one where the figures are genuinely absent, and only the former is something you can resolve by obtaining a delegation.

How do I monitor a customer for changes after onboarding?

Watch the change archive rather than re-running the onboarding check on a schedule. Re-checking every customer monthly costs in proportion to your customer count and still leaves a month-wide window in which you are acting on a stale answer. Polling /api/v1/changes with a stored cursor, or subscribing a webhook, costs in proportion to what actually changed.

Rank the triggers by consequence. A role change is the one that matters most, because it can change who is entitled to bind the company, which means any cached signing-authority answer you hold is now suspect and should be re-resolved rather than patched. A newly set bankruptcy or dissolution flag is the one that most obviously changes whether you should be trading at all. A change of name or address is usually a record update rather than a risk event.

Because the archive is append-only, it also answers the question a reviewer actually asks, which is when you first knew. A correction arrives as a new row rather than as an edit to an old one, so the sequence of what was observable and when stays reconstructable without depending on your own logging. The polling mechanics are covered in the guide on fetching updated company data.

Make the first call

The sandbox request needs no key. The TypeScript snippet runs the verification and authority calls under one correlation id and stores the evidence rather than the rendered result.

# Zero-auth sandbox: the verification verdict shape, synthetic company.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/verify

// One correlation id across the whole check makes it reconstructable.
const correlationId = crypto.randomUUID();
const headers = {
  Authorization: `Bearer ${process.env.APIER_API_KEY}`,
  "X-Correlation-ID": correlationId,
};
const base = "https://www.apier.no/api/v1/company/999999999";

// Check status before reading the body: an error envelope has no `data`,
// and a half-failed check is worse than a loud one.
const readOk = async (r: Response) => {
  const body = await r.json();
  if (!r.ok) {
    throw new Error(`${body.error_code}: ${body.explanation.summary}`);
  }
  return body;
};

const [verify, authority] = await Promise.all([
  fetch(`${base}/verify`, { headers }).then(readOk),
  fetch(`${base}/authority`, { headers }).then(readOk),
]);

// Store the hash and the id, not a screenshot of the page.
await recordCheck({
  correlationId,
  verdict: verify.data.verification_status,
  signing: authority.data.classification,
  hash: verify._meta.response_hash,
  servedAt: verify._meta.response_timestamp,
});

Frequently asked questions

Is this KYC or KYB?

KYB, meaning company-level verification. It establishes that a business exists, what form it takes, whether it is active, who is registered as able to act for it, and what it has filed. It does not verify the identity of a natural person, which in Norway is normally done with an electronic ID, and it is a separate exercise from a firm's own compliance programme.

What can I verify about a Norwegian company through an API?

Identity and organisational form from Enhetsregisteret, registration status and the bankruptcy and dissolution flags, signing authority and prokura from the open authority data, and annual accounts filing status from Regnskapsregisteret. Each response names its sources and states how fresh the data is.

How do I prove to an auditor that a check was performed?

Record the correlation id you sent, the response hash, and the response timestamp. The hash is a SHA-256 over the canonicalised response body, so it demonstrates that the bytes you acted on are the bytes that were served. That is stronger evidence than a stored screenshot, which proves only that something was displayed.

How often should I re-check a customer?

Re-checking on a timer is the expensive answer and it still misses things between runs. Subscribe to the change archive instead and react when something moves. A role change is the highest-value trigger, because it can alter who is entitled to bind the company and therefore invalidates any cached answer about signing authority.

Does this give me legal compliance advice?

No. It returns registry facts with their sources and freshness attached, which is evidence you can feed into your own process. What your obligations are, which counterparties they apply to, and what a sufficient check looks like in your sector are questions for your compliance function and your legal advisers.