Finnes det et samlet API for norske offentlige tjenester?
Nei. Norge har ikke ett offisielt API som dekker offentlige tjenester. Hver etat publiserer sin egen flate: Altinn 3 for skjemaer og delegert fullmakt, Brønnøysund for registerfakta, Skatteetaten for skattedata, NAV for arbeidsforhold, og hver av dem har sin egen legitimasjonsmodell, sine egne feltnavn og sin egen utgivelsestakt. Apier normaliserer disse kildene bak én Authorization: Bearer-nøkkel og én responskonvolutt, slik at et oppslag som ellers ville krevd fire koblinger blir ett enkelt HTTPS-kall mot et stabilt skjema.
Hvorfor har ikke Norge ett offisielt offentlig API?
Fordi hvert register ble bygget for sitt eget lovbestemte formål, på sitt eget tidspunkt, av etaten som er ansvarlig for det formålet. Enhetsregisteret finnes for å svare på hvem en juridisk enhet er. Skatteetatens flater finnes for å forvalte skatt. NAV holder arbeidsforhold og ytelser fordi NAV forvalter de ordningene. Ingen etat har mandat over en annen etats data, så det finnes ingen eier av et sammenslått bilde, og ingen budsjettpost for å vedlikeholde det.
Norge har kommet lenger enn de fleste land på den delen som faktisk lar seg sentralisere, nemlig identitet og tilgang. Digdir drifter Maskinporten som en felles maskin-til-maskin-tokentjeneste, og et bredt sett av etater godtar et Maskinporten-token som bevis på hvilken virksomhet som kaller. Altinn 3 legger til en felles plattform for skjemaer, meldinger og delegert fullmakt. Dette er reelle felles byggeklosser, og de fjerner reelt arbeid.
Det de ikke gjør, er å samle dataene. Et felles token slipper deg inn gjennom fire ulike ytterdører; det gjør ikke de fire rommene bak dem like. Du møter fortsatt ulike feltnavn for samme begrep, ulike vokabularer for selskapsstatus, ulike datoformater, ulik paginering og ulike feilformer. Det er i dette gapet integrasjonstiden faktisk går, og det er gapet et normaliserende lag finnes for å lukke.
Hva normaliserer et samlende lag egentlig?
Fire ting. Å være konkret betyr noe her, for ellers er «samlet» et tomt ord. For det første identitet: det 9-sifrede organisasjonsnummeret er koblingsnøkkelen på tvers av alle norske kilder, så ett selskapsnummer treffer alle sammen uten en oversettelsestabell du må vedlikeholde. For det andre feltnavn og typer: ett selskapsobjekt med ett sett navn, i stedet for fire objekter som staver status hver sin måte.
For det tredje opphav. Hver respons bærer en _meta-blokk som navngir data_source, rulebook_version, data_freshness og last_verified. Det betyr mer enn det høres ut som. Når du slår sammen fire kilder, slutter det ærlige spørsmålet om et felt å være «hva er verdien» og blir «hvilket register sa det, og når». En sammenslått respons uten opphav er en sammenslått respons du ikke kan etterprøve.
For det fjerde feil. Registre feiler i sine egne formater og på sine egne tidspunkter, og et sammenslått kall har flere måter å gå galt på enn et enkelt. Apier oversetter dem til en strukturert error_code med forklaring og rettesteg, lik i form på hvert endepunkt, og degraderer eksplisitt i stedet for stille: en delvis tilgjengelig kilde rapporteres som nettopp det på responsen, i stedet for å bli stille utelatt fra det sammenslåtte objektet.
Hvordan unngår jeg å bygge én kobling per etat?
Start fra koblingsnøkkelen, ikke fra endepunktlisten. Nesten hvert spørsmål en norsk integrasjon stiller, er forankret i et organisasjonsnummer, så det første kallet å gripe etter er /api/v1/company/{org}/context, som returnerer de åpne Brønnøysund-baserte feltene (navn, organisasjonsform, NACE-koder, status, kommune, rolleinnehavere) og legger til de lukkede kommersielle nøkkeltallene når du har en aktiv delegering for organisasjonen. Responsen forteller hvilket nivå du fikk gjennom data_tier, slik at koden din forgrener seg på et felt og ikke på en gjetning.
Har du et navn og ikke et nummer, løser /api/v1/company/search det opp og returnerer maksimalt ti kandidater med fem felter hver. Bruk det heller enn å konstruere et nummer: en 9-sifret verdi som tilfeldigvis består kontrollsifferet treffer et reelt selskap, bare ikke ditt. For å holde deg oppdatert erstatter endringsarkivet på /api/v1/changes polling per etat med én markørpaginert strøm av oppdagede endringer, som er dekket i veiledningen om å hente oppdaterte selskapsdata.
Bygg mot sandkassen før du har noen legitimasjon i det hele tatt. Hvert selskapsendepunkt har et nøkkelløst speil under /api/v1/sandbox/public/ som svarer med produksjonens responsform fra syntetiske testdata, og en ?simulate_error=-parameter injiserer manglende delegering, ugyldig token, validering og manglende scope, slik at feilhåndteringen din blir prøvd før den møter en reell feil. Det offentlige speilet godtar organisasjonsnummer 999999999 og avviser andre numre, noe som holder det tydelig at ingenting på den flaten er reelle data.
| Kilde | Bygge det selv | Gjennom Apier |
|---|---|---|
| Brønnøysund | Åpent og NLOD-lisensiert, så tilgangen er enkel. Du eier normaliseringen, mellomlagringen, ferskhetssporingen og oppførselen mot rategrenser. | Normalisert selskapsobjekt med opphav på responsen, servert fra en ferskhetsbevisst mellomlagring. |
| Altinn 3 | En Maskinporten-klient, et virksomhetssertifikat, signerte bruksvilkår, en oppføring i systemregisteret og en delegering fra hver kunde. | Meglet. Applikasjonen din sender én Bearer-nøkkel og håndterer aldri et offentlig token. |
| Skatteetaten | Scope-godkjenning per datasett, eget responsskjema og egne tilgjengelighetsegenskaper å designe rundt. | Skattesidens kontekst brettet inn i samme selskapsobjekt, med kilden navngitt på responsen. |
| NAV | En egen integrasjon med egen onboarding for arbeidsforhold og ytelser. | Leses gjennom samme nøkkel og samme konvolutt som alle andre kilder. |
| Holde seg oppdatert | En poller per etat, hver med sin egen oppfatning av hva som endret seg og når du får spørre igjen. | Én markørpaginert endringsstrøm på /api/v1/changes, filtrerbar på kilde og enhet. |
Gjør det første kallet
Sandkasseforespørselen under krever ingenting. TypeScript-snutten er produksjonsekvivalenten: samme stiform, én header lagt til.
# Nøkkelløs sandkasse: ingen nøkkel, sertifikat eller delegering.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/context// Ett kall som spenner over flere registre.
const res = await fetch(
"https://www.apier.no/api/v1/company/999999999/context",
{ 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, _meta } = await res.json();
// data_tier forteller deg om den lukkede Tier 2-blokken ble tatt med.
console.log(data.name, data.status, data.data_tier, _meta.data_freshness);Ofte stilte spørsmål
- Finnes det ett offisielt API for alle norske offentlige tjenester?
- Nei. Norge har ikke ett offisielt API for offentlige data. Digdir drifter felles byggeklosser, tydeligst Maskinporten for maskin-til-maskin-token, men de standardiserer hvordan du autentiserer deg, ikke hvordan dataene ser ut. Hver etat publiserer fortsatt sine egne endepunkter, sine egne feltnavn og sin egen utgivelsestakt.
- Teller Maskinporten som et samlet offentlig API?
- Maskinporten er en felles inngangsdør for autentisering, ikke for data. Tjenesten utsteder et access token som viser hvilken virksomhet som kaller, og stadig flere etater godtar det. Når du først har tokenet, står du likevel igjen med fire ulike responsskjemaer, fire vokabularer for status og fire feilformater.
- Hvilke kilder normaliserer Apier bak én nøkkel?
- Brønnøysund for registerfakta, Altinn 3 for skjemaer og delegert fullmakt, Skatteetaten for skattedata og NAV for arbeidsforhold. De svarer gjennom én Bearer-nøkkel og én responskonvolutt, med en _meta-blokk på hver respons som navngir datakilden, regelverksversjonen og hvor ferske dataene er.
- Kan jeg kalle registrene direkte i stedet?
- Ja, og for ett enkelt åpent oppslag er det ofte riktig valg. Brønnøysunds Enhetsregister er åpent tilgjengelig under NLOD og krever ingen legitimasjon i det hele tatt. Kostnaden ved å gå direkte dukker opp når du trenger flere etater koblet på samme selskap, konsistente ferskhetsdata og én feilkontrakt på tvers av alt sammen.
- Trenger jeg en API-nøkkel for å prøve et samlet oppslag?
- Ikke for å komme i gang. Hvert selskapsendepunkt har et nøkkelløst speil under /api/v1/sandbox/public/ som svarer med produksjonens responsform fra syntetiske testdata for organisasjonsnummer 999999999. Å lese reelle selskapsdata gjennom /api/v1/company/ krever nøkkel, fordi den flaten inneholder personnære felter som rolleinnehavere.