Hvordan spør jeg etter plikter mot Skatteetaten via API?
Av Antony Richard Grov, gründer av Apier
Pliktoppslag krever verken delegering eller nøkkel: spør /api/v1/public/obligations om en organisasjonsform, så får du malsettet tilbake, og fristkalenderen svarer på samme måte. Alt som er avgrenset til et navngitt selskap krever en API-nøkkel; det selskapsinterne nivået av fakta leveres ikke i dag, fordi Altinn-delegeringen det var avhengig av ikke lenger formidles. Én ting overrasker de fleste integratører: det finnes ikke noe Skatteetaten-scope på en Apier-nøkkel. Scopes på en Apier-nøkkel navngir datakilden framfor etaten innsendingen havner hos, så plikter og frister ligger under read:brreg. Maskinporten har sine egne scopes med etatsnavn, tildelt en registrert klient og presentert direkte overfor etatens API, og bare en direkte integrasjon forholder seg til dem.
Hva kan jeg sjekke uten en delegering?
Mer enn nok til å designe mot. Det nøkkelløse pliktendepunktet tar en organisasjonsform og returnerer malsettet for den, der hver oppføring bærer sin rettslige henvisning som et felt. Det nøkkelløse fristendepunktet tar et valgfritt år og returnerer den løpende kalenderen, med tidssone, hvilke organisasjonsformer hver oppføring gjelder for, og eventuell helgejustering eller helligdagsjustering allerede anvendt. Ingen av kallene navngir et selskap, så ingen av dem krever noens tillatelse.
Den kombinasjonen svarer på spørsmålet de fleste prosjekter faktisk starter med. Før du vet hvilke kunder du får, vil du vite hva et norsk aksjeselskap skylder, hvordan et enkeltpersonforetak skiller seg, og hvordan rapporteringsrytmen ser ut gjennom et år. Du kan bygge og teste hele formen på produktet ditt mot de to endepunktene og legge til selskapsspesifikk oppførsel senere.
Det du ikke får uten en nøkkel er noe som helst om en bestemt organisasjon, og det er en bevisst grense framfor en prisgrense. Selskapsdata berører styremedlemmer, signaturrett og innsendingsatferd, og derfor ligger de bak en identifisert kaller selv på gratisnivået. Veiledningen om automatisert regeletterlevelse dekker hvilke fakta som kan utledes av det åpne registeret og hvilke som ikke kan det.
Hvilke Skatteetaten-scopes finnes på en Apier-nøkkel, og hva dekker de?
Ingen, og grunnen er verdt å forstå fordi den sparer deg for en supporthenvendelse. Scopes på en Apier-nøkkel navngir datakilden kallet leser, ikke etaten den resulterende innsendingen til slutt går til. Så det finnes ingen read:skatteetaten å be om, og å be om en gir deg ingenting.
Hold den presiseringen i bakhodet hvis du har lest dokumentasjonen til Digdir, for det er der mesteparten av forvirringen oppstår. Maskinporten har sine egne scopes med etatsnavn, tildelt en registrert klient og presentert direkte overfor etaten selv. De er reelle, og de er et annet lag enn scopene på en Apier-nøkkel. Integrerer du direkte, forholder du deg til begge; et kall til Apier bærer bare Apier-nøkkelen, fordi det Apier svarer på ikke trenger noe etatsscope i det hele tatt.
Hva du faktisk trenger avhenger av hvilket endepunkt du kaller. Plikter, frister og selskapskontekst leser registerfakta, så de ligger under read:brreg. Innsendingshistorikken og flaten for prøveinnsending ble trukket tilbake 21. oktober 2026 sammen med de Altinn-baserte verktøyene og MVA-linjen; rutene svarer 410 CAPABILITY_WITHDRAWN uansett hvilket scope nøkkelen bærer. Sporingsloggen har sitt eget scope, read:audit, slik at en operatør kan gi selskapsdataoppslag uten samtidig å eksponere den forensiske loggen.
Prefiksene på skrivesiden finnes i vokabularet, men kan ikke tildeles noen nøkkel. Det betyr at en scopeliste er en faktisk oppføring over hvilke kilder en integrasjon berørte framfor en uttalelse om hvor mye den ble stolt på, og det er den egenskapen du vil ha når noen spør hva systemet ditt hadde tilgang til.
Hvordan ser jeg om en innsending allerede er gjort?
Ikke gjennom Apier. Oppslaget i innsendingshistorikken var avhengig av instansdata fra Altinn bak en kundedelegering, og det ble trukket tilbake 21. oktober 2026 sammen med de andre Altinn-baserte verktøyene; ruten svarer 410 CAPABILITY_WITHDRAWN. Databasen din vet hva produktet ditt sendte inn; den vet ikke hva kundens regnskapsfører sendte inn fra et annet sted sist fredag, og stedet som vet det, er Altinn selv, eller innleveringskanalen du bruker.
Behandle en innsendt periode som en stoppbetingelse før du handler, ikke som et avstemmingssteg i etterkant. En agent som sjekker historikken før den foreslår en innsending, unngår den verste feilmodusen på dette området, som er en dobbel innsending som deretter må rettes gjennom en prosess langt tregere enn den som skapte den. Å kombinere en historikksjekk i din egen kanal med oppslagene på plikter og frister gir deg begge halvdeler: om det er gjort, og om det overhodet forfalt.
Der en periode faktisk må sendes på nytt, er idempotensnøkkelen sikkerhetsnettet framfor din egen retry-logikk. En nøkkel gjør at et gjentatt kall spiller av det lagrede svaret i stedet for å kjøre to ganger, og det gjør en tvetydig nettverkstidsavbrudd om fra en beslutning du må ta til et kall du bare kan gjenta. Bygg det inn før du trenger det, for i det øyeblikket du trenger det, er det det siste du vil resonnere om.
Gjør det første kallet
Det første kallet trenger ingenting og returnerer hva et enkeltpersonforetak må sende inn. Det andre er det selskapsavgrensede historikkoppslaget, som krever en nøkkel og kundens delegering.
# Nøkkelløst: hva et norsk enkeltpersonforetak må sende inn.
curl -s "https://www.apier.no/api/v1/public/obligations?entity_type=ENK"// Er perioden allerede sendt inn? Les historikken.
// Bytt ut {org} med et ekte organisasjonsnummer; 999999999 finnes bare i sandkassen.
const res = await fetch(
"https://www.apier.no/api/v1/company/{org}/filing-history?limit=20",
{ headers: { Authorization: `Bearer ${process.env.APIER_API_KEY}` } },
);
const { data, _meta } = await res.json();
console.log(data.filings, _meta.data_freshness);Ofte stilte spørsmål
- Finnes det et Skatteetaten-scope jeg bør be om på Apier-nøkkelen min?
- Ikke på en Apier-nøkkel, og det overrasker folk. Scopes på en Apier-nøkkel navngir datakilden framfor etaten en innsending til slutt havner hos. Plikter og frister nås med read:brreg fordi inndataene er registerfakta. Det finnes ingen read:skatteetaten å be om, og rutene for innsendingshistorikk og prøveinnsending som brukte andre scopes, ble trukket tilbake 21. oktober 2026. Maskinporten-scopes med etatsnavn er et eget lag som bare en direkte integrasjon forholder seg til.
- Hva kan jeg spørre om helt uten delegering?
- Pliktmalen for en organisasjonsform, og den løpende fristkalenderen. Begge er nøkkelløse: ingen nøkkel, ingen delegering, ingen selskaper navngitt. Det dekker spørsmålet de fleste integrasjoner faktisk starter med, som er hva et norsk aksjeselskap eller enkeltpersonforetak må sende inn og omtrent når.
- Hva legger en delegering til?
- Ingenting gjennom Apier i dag. Hvert selskapsavgrenset svar bærer et data_tier-felt: tier_1 betyr åpne registerfakta, og tier_2, det selskapsinterne nivået, var avhengig av en Altinn-delegering Apier ikke lenger formidler eller leser siden 21. oktober 2026, så det beskriver seg selv som utilgjengelig. Et tier_1-svar er fullstendig over sine smalere inndata framfor avkortet, og svaret sier hvilke regler det ikke kunne nå.
- Hvordan sjekker jeg om en innsending allerede er gjort?
- Ikke gjennom Apier lenger. Oppslaget i innsendingshistorikken var avhengig av instansdata fra Altinn bak en kundedelegering, og det ble trukket tilbake 21. oktober 2026; ruten svarer 410 CAPABILITY_WITHDRAWN. Sjekk din egen innleveringskanal eller Altinn direkte. Det Apier svarer på, er om plikten gjelder og innen når den forfaller.
- Kan jeg sende inn til Skatteetaten gjennom dette API-et?
- Nei. Apier tilbyr verken innsending eller validering for innsending: MVA-linjen ble satt på vent 21. oktober 2026, og innsendingsrutene svarer 410 CAPABILITY_WITHDRAWN. API-et svarer på hva som må sendes inn, innen når og hvem som kan signere, og innsendingen skjer i din egen innleveringskanal.