Hva er en Altinn systembruker?

Det er en maskinidentitet som tilhører et kundeselskap og peker på et registrert system hos en leverandør. Selskapet gir den rettigheter i Altinn, og integrasjonen din opptrer deretter under den tildelingen framfor under noen ansatts innlogging. Systemet registreres én gang av leverandøren; systembrukeren opprettes per kunde, av den kunden.

Kan jeg ikke bare bruke en ansatts Altinn-innlogging i stedet?

Du kan teknisk sett automatisere en personlig innlogging, og det er en dårlig idé av grunner som dukker opp senere framfor med én gang. Tilgangen følger en person, så den forsvinner når vedkommende bytter rolle eller slutter, den bærer de rettighetene personen tilfeldigvis har framfor det smale settet integrasjonen din trenger, og sporingsloggen viser et menneske som gjør noe en maskin gjorde. Systembrukere finnes for å fjerne alle tre problemene.

Trenger jeg min egen Maskinporten-klient for systembrukerdelegering?

Bare hvis du integrerer direkte. Direkte betyr din egen Maskinporten-klient forankret i et virksomhetssertifikat, signerte bruksvilkår hos Digdir, og din egen oppføring i Altinn systemregister. Gjennom en megler tilhører de leddene megleren. Delegeringen per kunde er det ene leddet som ikke kan megles bort, fordi bare kunden kan gi rettigheter over sine egne forhold.

Hvordan vet jeg om en kundes delegering fortsatt gjelder?

Sjekk før du handler framfor etter at du har feilet. GET /api/v1/auth/permissions/{org} svarer HTTP 200 med en avgjørelse i data.status på full, partial eller none, pluss hvilke scopes som er aktive, hvilke som mangler, og norske fix_steps du kan vise kunden. Behandle en avgjørelse som ikke er full som en vanlig gren i koden, ikke som en feilsti.

Hva skjer hvis et selskap trekker tilbake tilgangen?

Neste myndighetssjekk gir en smalere avgjørelse, og enhver handling som var avhengig av de tilbaketrukne rettighetene er ikke lenger tillatt. Tilbaketrekking registreres som en ny tilstand framfor ved å slette den gamle tildelingen, så historikken om hva som var tillatt når overlever tilbaketrekkingen. Det betyr noe når du må forklare en handling som ble gjort for måneder siden.

Hvordan fungerer delegering til Altinn systembruker?

Et selskap gir et navngitt, registrert programvaresystem rett til å opptre på sine vegne i Altinn, avgrenset til bestemte tilgangspakker, uten at noen gir fra seg en personlig innlogging. Leverandøren registrerer systemet én gang. Hver kunde gjør deretter sin egen tildeling, og det er den tildelingen integrasjonen din opptrer under. Fordi myndigheten tilhører selskapet framfor en ansatt, overlever den utskiftninger av personale og kan når som helst snevres inn eller trekkes tilbake av selskapet.

Den øverste raden er arbeid leverandøren gjør én gang. Den stiplede pilen er delen som gjentas for hver kunde, og det er det eneste leddet en leverandør ikke kan gjøre på egne vegne.

Hva er forskjellen på en systembruker og en personlig Altinn-innlogging?

En personlig innlogging autentiserer et menneske. Alt som følger er avgrenset til det den personen har lov til å gjøre, som regel mye mer enn integrasjonen din trenger, og knyttet til at vedkommende fortsatt er ansatt. En systembruker autentiserer et system, for ett selskap, med et sett rettigheter selskapet har valgt bevisst. Forskjellen høres administrativ ut helt til første gang en regnskapsfører bytter jobb og halvparten av kundenes automatiseringer slutter å virke samme morgen.

Det finnes en annen forskjell som betyr mer for alt som er autonomt. Når en maskin opptrer med en persons legitimasjon, sier loggen at personen gjorde det. Det er ingen teknikalitet hvis handlingen var en innsending, og det er nær uforsvarlig hvis kalleren var en AI-agent. En systembruker holder loggen ærlig: systemet handlet, under en tildeling selskapet kan framvise, innenfor rettigheter selskapet valgte.

Modellen er dessuten den eneste som er åpen for kommersielle integratører. Altinn bekreftet i mai 2026 at serviceowner-instansscopes er forbeholdt offentlige etater, så det finnes ingen bredere dør å gå gjennom. Enhver privat integrasjon går gjennom kundedelegerte systembrukere, noe som betyr at delegeringsflyten ikke er et valgfritt lag du kan utsette.

Hvordan gir et selskap tilgang til systemet mitt?

Noen i selskapet som har myndighet til det, logger inn i Altinn, finner systemet ditt ved navn og gir det tilgangspakkene det trenger. En tilgangspakke er en bunt med rettigheter beskrevet i forretningsspråk framfor som rå endepunktsscopes, og det er det som gjør skjermbildet mulig å svare på for en økonomisjef og ikke bare for en utvikler. Jobben din i den flyten er stort sett å ha gjort systemet ditt mulig å finne, og å ha bedt om et sett pakker smalt nok til at den som godkjenner ikke nøler.

Før det skjermbildet finnes, er det oppsett på leverandørsiden: en Maskinporten-klient, signerte bruksvilkår hos Digdir, og en oppføring i Altinn systemregister slik at systemet ditt har et navn å bli funnet under. Gjennom en megler tilhører de tre megleren. Oppsettsveiledningen for systembrukere i dokumentasjonen går gjennom hele konfigurasjonen med tre ledd hvis du bygger den selv.

Når en tildeling først finnes, ikke gå ut fra den. Spør. Å kalle GET /api/v1/auth/permissions/{org} før en handling gir en avgjørelse på full, partial eller none, sammen med hvilke scopes som er aktive, hvilke som mangler, og norske fix_steps skrevet for å vises til kunden. Endepunktet svarer HTTP 200 i alle tre tilfellene, fordi «ikke autorisert ennå» er en tilstand i verden, ikke en feil ved forespørselen.

Hvordan håndterer jeg en delegering som er trukket tilbake?

Forvent det, og gjør det udramatisk. Et selskap kan snevre inn eller trekke tilbake en tildeling når det vil, og det kommer ikke til å si fra til systemet ditt først. Den praktiske følgen er at myndighetssjekken hører hjemme foran hver handling som avhenger av den, ikke én gang ved innrullering. Et lagret flagg om at «denne kunden er tilkoblet» i din egen database er en påstand om fortiden.

Utform tilbaketrekkingsstien som en produkttilstand framfor som en feil. Når avgjørelsen faller fra full til partial eller none, er den nyttige oppførselen å pause den berørte automatiseringen, vise fix_steps til kunden, og la alt som ikke var avhengig av de tilbaketrukne rettighetene fortsette. En integrasjon som svarer på en tilbaketrekking med en generisk feil, lærer kundene at produktet ditt er skjørt, når det som faktisk skjedde var at noen brukte en kontroll de var ment å ha.

Én detalj er verdt å kjenne fordi den former hva du kan svare på senere. En tilbaketrekking registreres som en ny tilstand oppå historikken, ikke ved å slette tildelingen som fantes. Så spørsmålet «hadde dette systemet lov til å gjøre det, den dagen det ble gjort?» forblir mulig å svare på etter at tilgangen er borte. Bygger du noe en kunde eller en revisor kan komme til å spørre om i ettertid, bør dine egne poster ha samme form.

Gjør det første kallet

De to kallene svarer på to ulike spørsmål som er lette å blande. Det første spør registeret hvem som i det hele tatt kan signere for et selskap. Det andre spør om det selskapet har gitt deg noe.

# Nøkkelløs sandkasse: hvem som kan signere, fra registeret.
curl -s https://www.apier.no/api/v1/sandbox/public/company/999999999/authority

// Delegert myndighet. Alltid HTTP 200; svaret ligger i kroppen.
const res = await fetch(
  "https://www.apier.no/api/v1/auth/permissions/999999999",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

const { data } = await res.json();

// "full" | "partial" | "none"
if (data.status !== "full") {
  // fix_steps er norsk tekst du kan vise kunden direkte.
  console.log(data.missing_scopes, data.fix_steps);
}

Ofte stilte spørsmål

Hva er en Altinn systembruker?: Det er en maskinidentitet som tilhører et kundeselskap og peker på et registrert system hos en leverandør. Selskapet gir den rettigheter i Altinn, og integrasjonen din opptrer deretter under den tildelingen framfor under noen ansatts innlogging. Systemet registreres én gang av leverandøren; systembrukeren opprettes per kunde, av den kunden.
Kan jeg ikke bare bruke en ansatts Altinn-innlogging i stedet?: Du kan teknisk sett automatisere en personlig innlogging, og det er en dårlig idé av grunner som dukker opp senere framfor med én gang. Tilgangen følger en person, så den forsvinner når vedkommende bytter rolle eller slutter, den bærer de rettighetene personen tilfeldigvis har framfor det smale settet integrasjonen din trenger, og sporingsloggen viser et menneske som gjør noe en maskin gjorde. Systembrukere finnes for å fjerne alle tre problemene.
Trenger jeg min egen Maskinporten-klient for systembrukerdelegering?: Bare hvis du integrerer direkte. Direkte betyr din egen Maskinporten-klient forankret i et virksomhetssertifikat, signerte bruksvilkår hos Digdir, og din egen oppføring i Altinn systemregister. Gjennom en megler tilhører de leddene megleren. Delegeringen per kunde er det ene leddet som ikke kan megles bort, fordi bare kunden kan gi rettigheter over sine egne forhold.
Hvordan vet jeg om en kundes delegering fortsatt gjelder?: Sjekk før du handler framfor etter at du har feilet. GET /api/v1/auth/permissions/{org} svarer HTTP 200 med en avgjørelse i data.status på full, partial eller none, pluss hvilke scopes som er aktive, hvilke som mangler, og norske fix_steps du kan vise kunden. Behandle en avgjørelse som ikke er full som en vanlig gren i koden, ikke som en feilsti.
Hva skjer hvis et selskap trekker tilbake tilgangen?: Neste myndighetssjekk gir en smalere avgjørelse, og enhver handling som var avhengig av de tilbaketrukne rettighetene er ikke lenger tillatt. Tilbaketrekking registreres som en ny tilstand framfor ved å slette den gamle tildelingen, så historikken om hva som var tillatt når overlever tilbaketrekkingen. Det betyr noe når du må forklare en handling som ble gjort for måneder siden.