Hvordan integrerer jeg med Altinn 3?
Altinn 3 er et REST-API, men du kan ikke kalle det med en API-nøkkel alene. Hvert kall trenger et Maskinporten-token som viser hvilken virksomhet du er, og alt som gjøres på vegne av en kunde trenger i tillegg en delegering til Altinn systembruker fra den kunden, som viser at du har lov til å opptre for dem. Apier megler begge leddene bak én enkelt Authorization: Bearer-header, slik at integrasjonen din blir et vanlig HTTPS-kall mot et normalisert skjema i stedet for en sertifikat- og token-kjede du bygger og vedlikeholder selv.
Hva er den enkleste måten å kalle Altinn 3-API-er på?
Altinn 2 ble lagt ned 19. juni 2026, så «Altinn 3» og «Altinn» betyr nå det samme. Det finnes ingen gammel vei å falle tilbake på, og heller ingen snarvei rundt autorisasjonsmodellen: Altinn bekreftet i mai 2026 at serviceowner-instansscopes er forbeholdt offentlige etater, så en kommersiell integratør går gjennom den kundedelegerte systembruker-modellen — eller ikke i det hele tatt.
Da står to ærlige valg igjen. Bygg legitimasjonskjeden selv — en Maskinporten-klient, et virksomhetssertifikat, signerte bruksvilkår, en oppføring i systemregisteret og en delegeringsflyt du tar hver eneste kunde gjennom — eller kall en megler som allerede har alt dette og eksponerer resultatet som et vanlig API. Apier er det andre valget: én Bearer-nøkkel, ett normalisert skjema, og token-utvekslingen mot Maskinporten og oppslaget av delegeringen skjer på den andre siden av kallet.
Det du får i dag, er lese- og verifiseringsflaten — selskapskontekst, plikter, frister, signaturrett og innsendingshistorikk — pluss tørrkjørt validering av en nyttelast før noe sendes inn. Bindende innsending er sandkassestyrt: du kan bygge hele kallformen mot syntetiske testdata, men en reell innsending forlater ikke systemet ennå. Den grensen er bevisst og oppgis på hver respons, slik at en agent kan skille et simulert resultat fra et reelt uten å gjette.
Trenger jeg fortsatt Maskinporten og virksomhetssertifikat?
Det kommer an på hvem som holder legitimasjonen, og skillet er renere enn det først ser ut. Maskinporten er Norges maskin-til-maskin- OAuth2-tjeneste: en klient autentiserer seg med en signert JWT-assertion, og nøkkelen bak den assertionen er forankret i et virksomhetssertifikat utstedt til en enhet registrert i Brønnøysund. En direkte integrasjon betyr at du skaffer sertifikatet, laster opp nøkkelen, signerer Digdirs bruksvilkår, registrerer systemet ditt i Altinn systemregister — og deretter roterer alt sammen etter en plan så lenge integrasjonen lever.
Gjennom en megler er ingenting av dette ditt. Apier holder sertifikatet, signerer assertionene og roterer nøklene; applikasjonen din sender én Bearer-nøkkel og ser aldri et offentlig token. Det en megler ikke kan ta fra deg, er delegeringen: at kunden din gir systemet ditt rett til å opptre for dem, er en beslutning bare den kunden kan ta, og ingen mengde infrastruktur fjerner den. Den praktiske forskjellen er at du integrerer mot én delegeringsflyt i stedet for også å eie en sertifikatlivssyklus. Vil du ha hele mekanikken i OAuth2-utvekslingen, dekker Maskinporten-guiden for utviklere token-flyten og fallgruvene fra ende til ende.
Hvordan tester jeg en Altinn 3-integrasjon uten produksjonstilgang?
Bruk den nøkkelløse sandkassen. Hvert selskapsendepunkt har et speil under /api/v1/sandbox/public/ som svarer med produksjonens responsform fra syntetiske norske selskapsdata, ikke krever noen API-nøkkel, og er deterministisk mellom kall — samme forespørsel gir samme kropp, så du kan asserte på den i en testsuite. Feilveiene er også testbare: en ?simulate_error=-parameter injiserer tilfellene manglende delegering, ugyldig token, valideringsfeil og manglende scope, slik at feilhåndteringen din blir kjørt før den møter en ekte feil.
Én egenskap betyr mer enn bekvemmelighet her: sandkassen kaller aldri et offentlig system. En levering i sandkassen er en lokal tilstandsendring, ikke en innsending som holdes tilbake — ingenting når Altinn, Maskinporten eller Skatteetaten fra den flaten. Sandkassen beviser altså at klienten din er riktig, og ingenting om en reell innsending, som er nøyaktig den garantien som gjør den trygg å peke en autonom agent mot. Start på sandkassen for en klar-til-bruk forespørsel, eller på hurtigstarten for gjennomgangen av første kall.
| Integrasjonsledd | Direkte mot Altinn 3 | Gjennom Apier |
|---|---|---|
| Autentisering | Din egen Maskinporten-klient, signerte JWT-assertions og et virksomhetssertifikat du skaffer og fornyer. | Én Bearer-nøkkel. Token-utvekslingen skjer på Apiers side; koden din håndterer aldri et offentlig token. |
| Fullmakt per kunde | En oppføring i systemregisteret pluss en delegering fra hver kunde, sporet og kontrollert av deg. | Fortsatt gitt av kunden, men slått opp og kontrollert for deg — signaturrett er et normalisert felt på responsen. |
| Responsform | Hvert register svarer i sitt eget skjema; du normaliserer på tvers av Brønnøysund, Altinn og Skatteetaten. | Ett normalisert skjema på tvers av kildene, med en _meta-konvolutt som bærer regelversjon og dataferskhet. |
| Feilhåndtering | Feil fra kildesystemet kommer i kildesystemets eget format; du oversetter hver enkelt til noe kalleren kan handle på. | Strukturert error_code pluss en forklaring med rettesteg, identisk i form på tvers av alle endepunkter. |
| Testmiljø | Tilgang til testmiljøer følger de samme onboarding-portene som produksjon. | Nøkkelløs sandkasse fra første minutt, med deterministiske testdata og eksplisitt feilinjeksjon. |
Gjør det første kallet
Sandkasse-forespørselen under trenger ingenting i det hele tatt — ingen nøkkel, intet sertifikat, ingen delegering. TypeScript-utdraget 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// Produksjonsoppslag. Én header — ingen token-utveksling i din kode.
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();
console.log(data.name, data.status, _meta.rulebook_version);Ofte stilte spørsmål
- Er Altinn 3 bare et REST-API jeg kan kalle med en API-nøkkel?
- Nei. Altinn 3 er et REST-API, men det utsteder ikke API-nøkler. Hvert kall bærer et Maskinporten-token som identifiserer virksomheten din, og alt du gjør på vegne av en kunde krever i tillegg at kunden har delegert tilgang til det registrerte systemet ditt. HTTP-kallet er den enkle delen; legitimasjonskjeden bak er arbeidet.
- Trenger jeg min egen Maskinporten-klient for å integrere med Altinn 3?
- Bare hvis du integrerer direkte. En direkte integrasjon betyr din egen Maskinporten-klient, et virksomhetssertifikat utstedt til en enhet registrert i Brønnøysund, signerte bruksvilkår hos Digdir, en oppføring for systemet ditt i Altinn systemregister, og en delegering fra hver eneste kunde. Gjennom en megler som Apier tilhører de fire første megleren; delegeringen per kunde tilhører fortsatt kunden din.
- Kan jeg bruke Altinns serviceowner-API-er i stedet for systembruker?
- Nei, og det kan ingen annen privat integratør heller. Altinn bekreftet i mai 2026 at serviceowner-instansscopes er forbeholdt offentlige etater. Enhver kommersiell integrasjon går gjennom den kundedelegerte systembruker-modellen, der hver kunde uttrykkelig gir rettigheter til det registrerte systemet ditt.
- Kan jeg teste en Altinn 3-integrasjon før jeg har produksjonstilgang?
- Ja. Apiers offentlige sandkasse er nøkkelløs og svarer med de samme responsformene som produksjon, fra syntetiske testdata, så du kan bygge og teste klienten før noe sertifikat eller noen delegering finnes. Sandkassen kaller aldri et offentlig system, som også er grunnen til at en levering i sandkassen beviser at kodeveien din virker, men ingenting om en reell innsending.
- Kan Apier levere en innsending til Altinn 3 på mine vegne i dag?
- Oppslag og validering er live: selskapskontekst, plikter, frister, signaturrett og innsendingshistorikk svarer mot reelle registerdata, og nyttelast kan valideres som tørrkjøring. Bindende innsending er sandkassestyrt i dag — utførelsesveien kjører mot syntetiske testdata, ikke en reell Altinn-innsending — så behandle det som en kontrakt du kan bygge mot, ikke en leveringsevne du kan lansere på.