Kan en AI-agent spørre mot og samhandle med Altinn-API-er?

Hva kan en agent gjøre i dag, og hva tilbys ikke?

Leseflaten er live og svarer mot reelle registerdata. En agent kan slå opp et selskap fra et navn, hente konteksten, spørre hva det må sende inn og når de neste fristene faller, og finne ut hvem som har signaturrett. Dette er vanlige autentiserte kall, de returnerer et normalisert skjema på tvers av Brønnøysund og regelboken, og hvert svar bærer regelversjonen og datafriskheten det ble produsert under.

Validering er det ikke. Utførelsesendepunktet med dry_run=true, som før kjørte en nyttelast gjennom regelmotoren og rapporterte hver sjekk, ble satt på vent sammen med MVA-linjen 21. oktober 2026 og svarer 410 CAPABILITY_WITHDRAWN. Ingenting på de skriveformede stiene kjører i dag, verken i produksjon eller i sandkassen.

Bindende innsending har aldri vært i drift, og den kommer ikke gjennom Apier. Altinn Servicedesk bekreftet skriftlig 21. oktober 2026, etter juridisk vurdering, at opplysninger fra Altinn Autorisasjon ikke kan være grunnlag for en kommersiell tjeneste, med eller uten systembruker, og MVA-linjen «agenten lager utkast, mennesket sender inn» står på vent til Digdir eller Skatteetaten svarer skriftlig på om en systemleverandør kan tilby den. Til da når en innsending Altinn slik den alltid har gjort: gjennom selskapets egen systembruker eller en person som logger inn.

Hvorfor er skrivesiden trukket tilbake og ikke bare styrt?

Fordi grunnen under den flyttet seg. Innsendingslinjen var bygget på to antakelser: at Apier kunne holde en systembruker i Altinn på vegne av en kunde, og at en leverandør kunne tilby MVA-innsending når scopet fra Skatteetaten kom. Den første ble besvart 21. oktober 2026: Altinn Servicedesk bekreftet, etter juridisk vurdering, at opplysninger fra Altinn Autorisasjon ikke kan være grunnlag for en kommersiell tjeneste, med eller uten systembruker. Apier trakk tilbake de Altinn-baserte fullmaktsverktøyene samme dag og leser ikke Altinn Autorisasjon i det hele tatt.

Den andre er åpen, og Apier behandler åpen som nei. MVA-linjen står på vent til Digdir eller Skatteetaten svarer skriftlig på om en systemleverandør kan tilby den, og en rute på vent svarer ikke med en falsk suksess eller en simulering: den svarer 410 CAPABILITY_WITHDRAWN med en forklaring, slik at en agent ikke kan forveksle den med en sperre som kanskje åpner ved nytt forsøk. Trukket tilbake er det ærlige ordet, fordi ingenting bak ruten kjører.

For agentdesign er den nyttige følgen at lesesiden er trygg å kalle spekulativt og komplett i seg selv. En agent som fastslår plikten, fristen og personen som kan signere, gir brukeren noe konkret å handle på. Veiledningen om MVA-fristene dekker tidshalvdelen av den forberedelsen i detalj.

Hvor ligger den menneskelige beslutningen nå?

I selskapet, hos personen med registrert myndighet som dekker steget. Det har alltid vært den rettslige posisjonen; det som er endret, er at Apier ikke lenger tilbyr en godkjenningsmekanisme rundt den. Scopeprefiksene som ville utløst en bindende handling er fortsatt reservert og kan ikke tildeles noen API-nøkkel, så ingen nøkkel i omløp kan snakkes til en innsending, men det finnes heller ingen ventende handling, ingen godkjenningslenke og ingen rute for menneskelig godkjenning å kalle. De rutene ble bygget for MVA-linjen og står på vent sammen med den.

Det Apier svarer på i stedet, er spørsmålet før godkjenningen: hvem som kan signere. /api/v1/company/{org}/authority returnerer den registrerte signaturretten og prokuraen fra Brønnøysund, med kilden og datoen den ble lest, og klassifiserer resultatet som alene, i fellesskap, etter rolle, bare prokura eller ingen myndighet. Et joint-svar betyr at to signaturer kreves, og riktig agentoppførsel er å overlate beslutningen til de personene framfor å prøve på nytt.

Formen for et produkt er altså uendret på agentens side: agenten forbereder, med plikten, fristen og signataren fastslått og med kilde, og en navngitt person bestemmer. Beslutningen tas i selskapets egne systemer, og innsendingen, der det er en, går gjennom selskapets egen kanal inn i Altinn.

Gjør det første kallet

Det første kallet trenger ingen nøkkel og sender ingenting: det leser hvem som kan signere for sandkasseselskapet. Det andre er fristoppslaget i produksjon, og feltet du handler på først er due_at.

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

// Les før du planlegger: fristene et selskap bærer, med regelversjonen
// på konvolutten. Ingenting sendes inn noe sted.
// Bytt ut {org} med et ekte organisasjonsnummer; 999999999 finnes bare i sandkassen.
const res = await fetch(
  "https://www.apier.no/api/v1/company/{org}/deadlines",
  { headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);

if (!res.ok) {
  // Alle ikke-2xx-svar bruker den samme strukturerte konvolutten.
  const { error_code, explanation } = await res.json();
  throw new Error(`${error_code}: ${explanation.summary}`);
}

const { data, _meta } = await res.json();
// Hver oppføring navngir plikten, perioden og den effektive,
// allerede helgejusterte fristen.
for (const entry of data.deadlines) {
  console.log(entry.obligation_id, entry.period_label, entry.due_at);
}
console.log(_meta.rulebook_version);

Ofte stilte spørsmål

Kan en AI-agent sende inn et skjema til Altinn i dag?

Ikke gjennom Apier. Apier sender ikke inn skjemaer til Altinn, validerer ikke nyttelast for innsending og har ingen systembruker for kundene dine. MVA-linjen ble satt på vent 21. oktober 2026, og de Altinn-baserte verktøyene ble trukket tilbake samme dag; hvert tilknyttet endepunkt svarer 410 CAPABILITY_WITHDRAWN. En agent når Altinn bare gjennom en systembruker selskapet selv godkjenner for et registrert leverandørsystem, utenfor Apier.

Hva får en agent ut av sandkassen da?

Bevis på at lesestien din er riktig. Sandkassen svarer med produksjonens responsform fra syntetiske testdata, deterministisk, så du kan asserte mot den i en testsuite, og den kan injisere feiltilfeller på forespørsel slik at feilhåndteringen din blir prøvd. Den kaller aldri et offentlig system på noe verb, og den har ingen innsendingsvei.

Hva skjedde med prøveinnsendingen?

Den ble trukket tilbake sammen med MVA-linjen. Utførelsesendepunktet med dry_run=true sjekket før en reell nyttelast mot regelsettet; siden 21. oktober 2026 svarer det 410 CAPABILITY_WITHDRAWN, som alle andre innsendingsruter. Lesingen ble aldri berørt: plikter, frister og signaturrett svarer som før.

Hvem godkjenner en bindende innsending, da?

En person i selskapet med registrert myndighet som dekker den, i selskapets egen kanal. Delen til Apier er å si hvem det er: GET /api/v1/company/{org}/authority returnerer signaturrett og prokura fra Brønnøysund med kilde og dato, slik at agenten kan sende beslutningen til riktig menneske i stedet for å gjette.

Hvordan vet jeg hvilken funksjonalitet som er live akkurat nå?

To kilder, og de stemmer overens som følge av konstruksjonen. GET /api/v1/capabilities returnerer et maskinlesbart statusfelt på hver funksjon, og det er den å lese hvis du er en maskin. Statussiden for funksjonalitet i dokumentasjonen er den menneskelesbare ekvivalenten og sier uttrykkelig at den kan henge etter API-et.