Hopp til innhold

Hvorfor Apier

Norge har en strukturell mulighet. Apier henter den hjem.

Suveren friksjon: det er reelt at norsk regelverk er spesifikt, og Norge bør vinne på det. Apier er laget som oversetter regelverket til det maskinlesbare verdiktet en integrasjon med automatisering trenger.

Tesen

Altinn, Brønnøysundregistrene, Maskinporten og Skatteetaten er offentlig infrastruktur norske selskaper, regnskapsbyrå og myndighetstjenester bruker hver virkedag. Portalene er dokumentert. API-et finnes. Det juridiske rammeverket er publisert på Lovdata. Det som mangler, er laget som oversetter alt dette til ett deterministisk, maskinlesbart svar en integrasjon kan planlegge mot. Automatiserte flyter leser ikke norske PDF-forskrifter. De utleder ikke fra Brønnøysundroller hvilken person som kan levere MVA på vegne av hvilken enhet. De holder ikke styr på endringer i aksjeloven. Dette arbeidet utføres én gang, korrekt, av et lite antall norske etterlevelsesspesialister i dag, og det gjenskapes dårlig, i det stille, av hvert team som forsøker å integrere. Apier finnes for å gjøre det én gang og eksponere det som et API.

Hva som strukturelt mangler

Det som mangler, er et oversettelseslag mellom fire flyter i bevegelse, ikke ett enkelt endepunkt:

  • Altinn 3-delegering som maskinell tilstand. Altinn returnerer hvem som har fått hvilke tilgangspakker på vegne av hvilken organisasjon. Det svarer ikke på spørsmålet en integrasjon stiller i neste steg: gitt denne delegeringsmengden, hvilke av handlingene brukeren ønsker er juridisk autorisert, og hva mangler hvis noen av dem ikke er det.
  • MVA-terskler og forpliktelseskadens. MVA-registreringsterskelen, valget mellom termin annenhver måned og årlig termin, revisjonsterskelen ved 7 millioner NOK i omsetning, årsregnskapsfristen som forskyves i helger: Alt dette er kodifisert i skatteforvaltningsloven, MVA-loven, aksjeloven og en stabel forskrifter. Ikke noe offentlig API returnerer det samlede verdiktet for en gitt organisasjon. Hver integratør betaler enten en etterlevelsesspesialist for å lese reglene eller hardkoder et skjørt utvalg.
  • Brønnøysundroller i norske PDF-er. Daglig leder, styremedlem, signaturrett, prokura, innehaver: Rolletaksonomien som avgjør hvem som kan handle for en enhet, er spredt over Brønnøysundregistrene, aksjeloven og praksis rundt rollene. Dataene er publisert; den operative koblingen fra rolle pluss handling til «ja, denne personen kan signere den leveransen» er det ikke.
  • Maskinporten som livssyklus for legitimasjon. Maskinporten er en ren OAuth2-server. Rundt det sitter utstedelse av virksomhetssertifikat, registrering i Samarbeidsportalen, godkjenningsrunder for scopes, nøkkelrotasjon, og delingen mellom test- og produksjonsmiljø. Kostnaden ved å gjøre dette én gang per integrerende team er kostnaden for en seniorutvikler i flere uker per team, hvert år.

Hvem Apier er for, og hvem det ikke er for

Apier er for de som bygger, og som trenger verdiktet, ikke for sluttbrukere som trenger en portal.

  • Plattformer for integrasjoner med automatisering. MCP-kompatible verktøykjeder, orkestrerte arbeidsflyter, skreddersydde integrasjonsflater. Verktøyene en automatisert flyt kaller bør være deterministiske, daterte og juridisk siterbare. Apier leverer den formen over både REST og Model Context Protocol.
  • Integratører som kobler automatiserte flyter mot norsk signaturrett. Teamet som bygger en intern integrasjon som leverer MVA, sjekker en revisor-terskel, eller validerer en Altinn 3-delegeringskjede før handling. Apier fjerner integrasjonsskatten slik at integratøren kan fokusere på arbeidsflyten.
  • Utenlandske selskaper med drift i Norge. Norsk selskapsrett og registrene bak den er fulle av særnorske detaljer. Apier returnerer det samme strukturerte svaret uansett hvilket land integrasjonen kjører fra, slik at teamet ikke trenger å ansette en norsk spesialist for å levere.
  • Leverandører av regnskapssystemer. Tripletex, Fiken, Conta, PowerOffice og deres jevnaldrende eier den menneskelige arbeidsflyten. Apier betjener integrasjonslaget under, slik at leverandørteam kan levere Altinn 3-delegering og forpliktelseslogikk uten å eie Maskinporten-livssyklusen internt.
  • Ikke målgruppen: privatpersoner som leverer egen skattemelding, sluttbrukere som leverer for seg selv, eller team med engangsoppslag. Etatenes egne portaler dekker disse godt, og Apier er bevisst utenfor det sporet.

Vollgraven

Norge har 5,5 millioner innbyggere. Det er omtrent befolkningen til en mellomstor europeisk storby. Regnestykket betaler ikke for at en global plattform skal bygge et landsspesifikt oversettelseslag for regelverk i denne målestokken: integrasjonen er for spesifikk, regelkadensen for lokal, og kundebasen for liten til å lande på et lysbilde på en årlig produktgjennomgang i Silicon Valley. Det samme regnestykket virker omvendt for et team forankret nasjonalt: oversettelse av regelverk, integrasjon med myndighetenes API, og reviderbar herkomstdokumentasjon er nettopp den produktformen som skalerer sublineært med befolkning og superlineært med regelkompleksitet. Det relevante spørsmålet er om et norsk team leverer et deterministisk, siterbart API for integrasjoner med automatisering før vinduet lukkes, ikke om en global aktør vil konkurrere på denne flaten. Apier er det veddemålet.

FAQ

Hvorfor rute gjennom Apier i stedet for å kalle Altinn, Brønnøysund eller Skatteetaten direkte?
Etatene eksponerer rådata. Apier oversetter rådataene til det verdiktet en integrasjon trenger før den handler: hvem som har lov til å levere hva, når neste frist lander i Europe/Oslo, hvilket Maskinporten-scope som autoriserer et bestemt Altinn 3-endepunkt, hvilken MVA-termin et gitt organisasjonsnummer skylder. Direkte kall er gratis og fornuftig hvis programvaren din trenger én rad fra ett register. Hvis integrasjonen din skal planlegge eller handle på tvers av registre, vipper integrasjonskostnaden over til Apier.
Hentes dataene i sanntid eller fra mellomlager, og hvor ferske er de?
Brønnøysund-selskapstilstand avstemmes ved lesning med en kort cache; Altinn 3-fullmakter løses per forespørsel fordi de er den juridiske kroken for hvem som kan handle. Hvert svar bærer en _meta-blokk med rulebook_version, data_freshness og last_verified slik at en integrasjon kan avgjøre om den skal planlegge på nytt eller gå videre. Apier er deterministisk: samme inndata og samme regelbokversjon gir identisk utdata, byte for byte.
Hvor lagres dataene? Forlater noe Norge eller EU?
Primærdata ligger i Supabase EU (Stockholm). Bygg og drift går på Vercels kantnettverk i EU, og en migrering bort fra Vercel er planlagt før reelle kundedata flyter. Den maskinlesbare attestasjonen på /.well-known/data-sovereignty publiserer underleverandørliste, regioner og DPA-status slik at innkjøpsteam og integrasjoner kan verifisere det uten å spørre oss. Se også vår side om tillit og åpenhet.
Hvem er Apier for, og hvem er det ikke for?
Typisk bruker er en plattform som bygger integrasjoner med automatisering mot norsk regelverk, en integratør som kobler en automatisert flyt til norsk signaturrett og selskapsroller, et utenlandsk selskap som må handle i Norge uten å ansette en norsk spesialist til å lese registrene, eller en regnskapssystemleverandør som trenger Altinn 3-delegering uten å eie Maskinporten-livssyklusen selv. Apier er ikke for sluttbrukere som leverer skattemeldingen sin selv (det er Skatteetatens flate), og ikke for engangsoppslag, der det er billigere å kalle Brønnøysund direkte.
Hvordan skiller Apier seg fra Visma, Tripletex eller andre norske regnskapsplattformer?
Regnskapsplattformer eier den menneskelige arbeidsflyten: regnskap, fakturering, lønn, det synlige grensesnittet et regnskapsteam bruker. Apier er laget under, eksponert som et API. En regnskapsplattform kan bygge på Apier på samme måte som en integrasjon kan (få forpliktelsesverdiktet, fristen, fullmaktskjeden, det strukturerte feilomslaget) uten å bygge Maskinporten- og Altinn 3-rørleggingen på nytt internt. Apier konkurrerer ikke med det menneskerettede produktet; det betjener integrasjonslaget de produktene allerede trenger.

Videre lesning

  • /sandbox: den åpne sandkassen uten autentisering, med eksempler på forpliktelser, frister og autorisasjonsverdikter som du kan kjøre med curl.
  • /docs: utviklerdokumentasjonen, inkludert OpenAPI-spesifikasjonen, MCP-serverens konfigurasjon, og Compliance Explainer-feilkatalogen.
  • /trust: datasuverenitet, GDPR-grunnlag, underleverandørliste, og løpende oppdatert regelbokhistorikk.
  • /no/altinn3-overgang: bokmålssiden om Altinn 2 → Altinn 3-overgangen 19. juni 2026, med tilordningen til tilgangspakker og fristberegningen.
  • /use-cases/altinn-migration: den engelske søsterflaten for Altinn 2 → Altinn 3-overgangen.
  • /blog/altinn-3-migration-for-developers: utviklerrettet migrasjonsguide med kodeeksempler og det strukturerte feilomslaget.
  • /blog/maskinporten-guide: innføring i Maskinporten som dekker klientoppsett, tokenets livssyklus og delegeringsstien for Altinn System User.