Hvordan verifiserer jeg et selskaps signaturrett via API?

Hva er forskjellen på signaturrett og prokura?

Det er to ulike fullmakter et norsk selskap kan registrere, og å blande dem er den vanligste feilen på dette området. Signaturrett er den generelle fullmakten til å binde selskapet. En person som har den, kan inngå avtaler på selskapets vegne på tvers av virksomhetens forhold, med forbehold om den kombinasjonen registeret har notert.

Prokura er en snevrere forretningsfullmakt. Den dekker den ordinære driften av virksomheten, og etter vanlig oppfatning strekker den seg ikke til å råde over selskapets faste eiendom. I praksis betyr det at en person med prokura og uten signaturrett kan gjøre svært mye i det daglige og likevel ikke kunne signere akkurat det dokumentet du har foran deg. En respons klassifisert som prokura_only er nøyaktig den situasjonen, og å behandle den som likeverdig med sole er slik en automatisert kontroll ender med å godta en signatur som ikke binder noen.

Begge er registrert, begge er åpne data, og en person kan ha den ene, begge eller ingen. Responsen returnerer dem som separate lister, signaturrett_holders og prokura_holders, slik at koden din aldri må utlede den ene fra den andre. De samme to feltene finnes også på /api/v1/company/{org}/context som åpne Tier 1-lister, når du vil ha innehaverne sammen med resten av selskapsoppføringen i stedet for alene.

Hvordan sjekker jeg om én person kan signere alene?

Forgren på classification i stedet for å lese innehaverlisten og gjette. Verdien sole betyr at én registrert innehaver kan binde selskapet på egen hånd. joint betyr at signaturer må kombineres, så én signatur er ikke nok uansett hvem som avgir den. by_role betyr at fullmakten henger på en rolle som styreleder eller daglig leder og ikke på navngitte personer. no_authority betyr at ingenting kvalifiserende er registrert, og unknown betyr at spørsmålet ikke lot seg avklare.

Behandle unknown som sin egen gren, verken som en feil eller som en godkjenning. Det er en ærlig konklusjon om de tilgjengelige dataene og ikke en feilmelding, og å slå den sammen med en av naboene er slik en kontroll stille blir feil. Feltet summary bærer en lesbar setning som beskriver ordningen, og det er den du bør vise et menneske når koden din har konkludert med at den ikke kan gå videre automatisk.

Sjekk kombinasjon_available før du behandler noen konklusjon som endelig. Signaturkombinasjonene hentes live ved hvert kall, og når det oppslaget er utilgjengelig kommer flagget tilbake som false, og klassifiseringen faller tilbake på de registrerte rolleinnehaverne pluss eventuelle prokurakombinasjoner hentet separat. Kallet feiler bevisst ikke i den situasjonen, noe som er riktig for tilgjengelighet og feil å overse i en beslutning: en konklusjon basert på reserveløsningen er svakere bevis enn en fullt underbygget.

Hvilket register holder disse dataene?

Brønnøysund, gjennom to åpne flater. Rolledataene kommer fra Enhetsregisteret, som noterer hvem som har hvilken posisjon i en registrert enhet. Signaturkombinasjonene kommer fra Fullmakttjenesten, og det er den delen som betyr mest her: Brønnøysund anvender de lovbestemte signaturreglene på sin egen side og publiserer kombinasjonen som følger, så det tunge tolkningsarbeidet er allerede gjort av registeret som eier spørsmålet.

Den arbeidsdelingen er grunnen til at dette endepunktet kan være ærlig om sine egne grenser. Apier kategoriserer publisert registerresultat i et lite lukket vokabular og navngir kildene sine på hver respons gjennom data_sources. Tjenesten holder ingen privat modell av norsk selskapsrett, og en side som antydet noe annet ville hevdet en autoritet koden ikke har.

Begge flatene er åpne og NLOD-lisensierte, så dataene i seg selv er ikke lukket. Å lese dem gjennom /api/v1/company/ krever likevel API-nøkkel, fordi responsen navngir personer, og personnære data ligger bak autentisering også på gratisnivået. Vil du ha registermekanikken i mer dybde, dekker referansen om signaturrett i norske selskaper detaljene på feltnivå.

Gjør det første kallet

Sandkasseforespørselen krever ingen nøkkel. TypeScript-snutten viser produksjonsformen med hver klassifiseringsgren håndtert eksplisitt, inkludert sjekken av degradert kilde.

# Nøkkelløs sandkasse: samme responsform, syntetisk selskap.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/authority

// Kan én person signere alene? Forgren på klassifiseringen, ikke på navn.
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) {
  // Oppslaget mot signaturkombinasjoner var utilgjengelig. Regn som uavklart.
  console.warn("Degradert: klassifisert kun fra rolleinnehavere.");
}

switch (data.classification) {
  case "sole":
    break; // Én innehaver kan binde selskapet alene.
  case "joint":
  case "by_role":
  case "prokura_only":
  case "no_authority":
  case "unknown":
    throw new Error(`Ikke enesignatur: ${data.summary}`);
}

Ofte stilte spørsmål

Hva er forskjellen på signaturrett og prokura?

Signaturrett er fullmakten til å binde selskapet generelt, også i beslutninger om virksomheten selv. Prokura er snevrere: den dekker den daglige forretningsdriften og omfatter etter vanlig oppfatning ikke å råde over selskapets faste eiendom. En person kan ha den ene, begge eller ingen av dem, og å ha prokura alene gjør ingen til generell signatar.

Kan jeg sjekke signaturrett uten API-nøkkel?

Du kan øve på nøyaktig samme responsform uten nøkkel. Det nøkkelløse sandkassespeilet svarer på /api/v1/sandbox/public/company/999999999/authority fra syntetiske testdata. Å slå opp et reelt selskap krever API-nøkkel, fordi responsen navngir rolleinnehavere, som er personnære data snarere enn åpen infrastruktur.

Sier API-et om en bestemt person kan signere?

Det sier hvordan selskapets signaturrett er strukturert og hvem de registrerte innehaverne er. Feltet classification svarer på om én innehaver kan opptre alene, om signaturer må kombineres, eller om bare prokura er registrert. Å matche det mot et navngitt menneske foran deg er et steg du fortsatt utfører selv.

Hva skjer om Brønnøysunds signaturoppslag er utilgjengelig?

Kallet svarer likevel, med kombinasjon_available satt til false. Klassifiseringen hviler da på de registrerte rolleinnehaverne pluss eventuelle prokurakombinasjoner hentet separat, noe som er svakere bevis enn de fulle kombinasjonsdataene. Sjekk det flagget før du behandler en konklusjon som endelig, i stedet for å anta at alle responser er like godt underbygget.

Er dette en juridisk vurdering av hvem som kan signere?

Nei. Det gjengir hva registeret inneholder, normalisert til en stabil form, med datakildene navngitt på hver respons. Brønnøysund anvender de lovbestemte signaturreglene og publiserer kombinasjonene som følger; Apier kategoriserer det publiserte resultatet i stedet for å tolke lovgivning. I en omtvistet eller uvanlig sak er registeroppføringen og juridisk rådgivning fortsatt autoriteten.