How do I verify company signing authority (signaturrett) via API?

What is the difference between signaturrett and prokura?

They are two different authorities that a Norwegian company can register, and conflating them is the most common mistake in this area. Signaturrett is the general authority to bind the company. A person holding it can enter agreements on the company's behalf across the range of its affairs, subject to whatever combination the register records.

Prokura is a narrower commercial authority. It covers the ordinary running of the business, and by convention it does not extend to dealing in the company's real property. In practice this means a person with prokura and no signaturrett can do a great deal of day-to-day business and still be unable to sign the specific document in front of you. A response classified prokura_only is exactly that situation, and treating it as equivalent to sole is how an automated check ends up accepting a signature that does not bind anyone.

Both are registered, both are open data, and a person may hold one, both or neither. The response returns them as separate arrays, signaturrett_holders and prokura_holders, so your code never has to infer one from the other. The same two fields also appear on /api/v1/company/{org}/context as open Tier 1 arrays when you want the holders alongside the rest of the company record rather than on their own.

How do I check whether one person can sign alone?

Branch on classification rather than reading the holder list and guessing. A value of sole means a single registered holder can bind the company by themselves. joint means signatures must be combined, so a single signature is not enough no matter who provides it. by_role means the authority attaches to a role such as chair or general manager rather than to named individuals. no_authority means nothing qualifying is registered, and unknown means the question could not be resolved.

Handle unknown as its own branch, not as a failure and not as a pass. It is an honest verdict about the available data rather than an error, and collapsing it into either neighbour is how a check quietly becomes wrong. The summary field carries a readable sentence describing the arrangement, which is what to surface to a human reviewer once your code has decided it cannot proceed automatically.

Check kombinasjon_available before treating any verdict as conclusive. The signing combinations are fetched live on each call, and when that lookup is unreachable the flag comes back false and the classification falls back to the registered role holders plus any prokura combinations retrieved separately. The call deliberately does not fail in that situation, which is the right behaviour for availability and the wrong thing to ignore in a decision: a fallback-sourced verdict is weaker evidence than a fully sourced one.

Which register holds this data?

Brønnøysund, across two open surfaces. The role data comes from Enhetsregisteret, which records who holds which position in a registered entity. The signing combinations come from Fullmakttjenesten, which is the part that matters most here: Brønnøysund applies the statutory signing rules on its own side and publishes the resulting combination, so the hard interpretive work has already been done by the register that owns the question.

That division is why this endpoint can be honest about its own limits. Apier buckets published register output into a small closed vocabulary and names its sources on every response through data_sources. It does not hold a private model of Norwegian company law, and a page that implied otherwise would be claiming an authority the code does not have.

Both surfaces are open and NLOD-licensed, so the data itself is not gated. Reading it through /api/v1/company/ still requires an API key, because the response names individuals and personal-adjacent data sits behind authentication even on the free tier. If you want the underlying register mechanics in more depth, the signature rights reference covers the field-level detail.

Make the first call

The sandbox request needs no key. The TypeScript snippet shows the production shape with every classification branch handled explicitly, including the degraded-source check.

# Zero-auth sandbox: the same response shape, synthetic company.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/authority

// Can one person sign alone? Branch on the classification, not on names.
const res = await fetch(
  "https://www.apier.no/api/v1/company/999999999/authority",
  { 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 } = await res.json();

if (!data.kombinasjon_available) {
  // The signing-combination lookup was unreachable. Treat as unresolved.
  console.warn("Degraded: classified from role holders only.");
}

switch (data.classification) {
  case "sole":
    break; // One holder can bind the company alone.
  case "joint":
  case "by_role":
  case "prokura_only":
  case "no_authority":
  case "unknown":
    throw new Error(`Not a sole signatory: ${data.summary}`);
}

Frequently asked questions

What is the difference between signaturrett and prokura?

Signaturrett is the authority to bind the company generally, including decisions about the business itself. Prokura is narrower: it covers day-to-day commercial dealings and conventionally excludes things such as dealing in the company's real property. A person can hold one, both or neither, and holding prokura alone does not make someone a general signatory.

Can I check signing authority without an API key?

You can rehearse the exact response shape without one. The zero-auth sandbox mirror answers /api/v1/sandbox/public/company/999999999/authority from synthetic fixtures. Resolving a real company requires an API key, because the response names role holders, which is personal-adjacent data rather than open infrastructure.

Does the API tell me whether a specific person can sign?

It tells you how the company's signing authority is structured and who the registered holders are. The classification field answers whether a single holder can act alone, whether signatures must be combined, or whether only prokura is registered. Matching that against a named individual in front of you is a step you still perform.

What happens if Brønnøysund's signing lookup is unavailable?

The call still answers, with kombinasjon_available set to false. The classification then rests on the registered role holders plus any prokura combinations fetched separately, which is weaker evidence than the full combination data. Check that flag before treating a verdict as conclusive rather than assuming every response is equally well-sourced.

Is this a legal opinion on who may sign?

No. It reports what the register holds, normalised into a stable shape, with the data sources named on every response. Brønnøysund applies the statutory signing rules and publishes the resulting combinations; Apier buckets that published output rather than interpreting legislation. For a contested or unusual case, the register entry and legal advice remain the authority.