What is the difference between Altinn 2 and Altinn 3?

Altinn is Norway's shared platform for digital dialogue between businesses and the public sector. Altinn 2 is the older generation (SOAP services, role-based authorisation); Altinn 3 is the current generation (REST + the Instances API, access-package-based authorisation, and System Users for machine-to-machine access). DigDir is decommissioning Altinn 2 on 19 June 2026, after which Altinn 3 is the Altinn API — older Altinn 2 endpoints stop responding.

Do I still need a System User and Maskinporten if I use Apier?

Your code does not. Apier's Auth Gateway owns the Maskinporten client-assertion flow and the Altinn 3 System User delegation handshake; your integration sends one Bearer API key. Each organisation you act for grants your Apier account an Altinn 3 System User delegation (a one-time client-side step), and Apier resolves the right token and scopes at request time. Raw OAuth tokens never leave the gateway.

What happens to my Altinn 2 integration on 19 June 2026?

It stops working that day. Altinn 2 roles do not automatically carry over to Altinn 3 access packages, so each organisation needs a fresh Altinn 3 System User delegation. Apier exposes the Altinn 2 role to Altinn 3 access-package mapping as a zero-auth lookup at /api/v1/tools/altinn-migration; the deadline math and the caveat that one Altinn 2 role often splits across multiple Altinn 3 packages are covered on /use-cases/altinn-migration.

Can I file to Altinn 3 through Apier?

Filing actions run through POST /api/v1/actions/execute. With ?dry_run=true the endpoint runs five preflight checks — company exists, System User authorised, scopes delegated, payload format valid, and a deadline-window guard that currently treats every action as unconstrained until the obligation-to-deadline mapping is enabled — and returns a structured outcome without submitting. The live path requires an Idempotency-Key, a single-use approval token, and an active delegation; mva_melding is the live-wired action type at v1, with the production Altinn 3 submission gated on Maskinporten production approval. Every successful submission returns an HMAC-signed receipt envelope.

How do I try the Altinn-backed endpoints without credentials?

Every Category B company endpoint has a zero-auth sandbox mirror under /api/v1/sandbox/public/ against the synthetic fixture org 999999999. The response shape matches production (including the data.* blocks that carry Altinn delegation state), so you can wire and test your client before provisioning a key. The /sandbox page lists copy-paste cURL for each route.

Developer API

Altinn API

Altinn 3 integration — without rebuilding the System User, Maskinporten, and delegation stack yourself.

Read the docs Try the sandbox

Altinn is Norway's shared platform for digital dialogue between businesses and the public sector — filings, forms, correspondence, and machine-to-machine APIs spanning Skatteetaten, Brønnøysund, NAV, and dozens of other agencies.

After 19 June 2026, Altinn 3 is the Altinn API

DigDir is decommissioning Altinn 2 on 19 June 2026. The older Altinn 2 services — SOAP endpoints, role-based authorisation — stop responding that day, and Altinn 3 (REST, the Instances API, access-package authorisation, and System Users for machine access) becomes the only Altinn API. Building against it directly means owning several moving parts at once:

A machine identity. A virksomhetssertifikat from Buypass or Commfides, a Maskinporten client with an RSA keypair, and an Altinn System Register entry — before a single request authenticates.
Per-organisation authority. Each organisation you act for must grant a System User delegation scoped to the right access packages (tilgangspakker). Delegations expire, get revoked, and have to be re-granted on the organisation's side.
The Altinn 2 → Altinn 3 mapping. An old Altinn 2 role rarely maps one-to-one onto an Altinn 3 access package — one role often splits across several packages, or several roles collapse into one. Getting the mapping wrong fails closed at the gateway.

What Apier brokers for you

Apier's Auth Gateway owns the Maskinporten JWT client-assertion flow, token caching, and the Altinn 3 System User delegation handshake. Your integration sends one Bearer API key; the gateway resolves the correct Maskinporten token and the organisation's delegation scopes at request time, and never returns the raw OAuth token to your code.

One credential, N organisations. One enterprise certificate and one Maskinporten client live at the gateway; per-organisation authority comes from each org's Altinn 3 System User delegation. Expired or revoked delegations fail closed.
Reconciled cross-agency state. The same surface that exposes Altinn delegation state reconciles Brønnøysund (entity registry), Skatteetaten (MVA-register, MVA-meldinger), and NAV (Aa-registeret aggregates) into one normalised company context.
Filing with a safety gate. POST /api/v1/actions/execute runs a dry-run validation path (five preflight checks, no submission) and a live path gated on a single-use approval token plus an active delegation — so automation never bypasses a human gate.

What a call looks like

The company context endpoint returns the org's Altinn 3 delegation state alongside the reconciled registry data. Start against the zero-auth sandbox, then point the same client at the production host with your key.

# Zero-auth sandbox — synthetic fixture org 999999999.
# data.* mirrors the production shape, including Altinn delegation state.
curl https://www.apier.no/api/v1/sandbox/public/company/999999999/context

# Production — one Bearer API key; the per-org authority comes from
# the org's active Altinn 3 System User delegation, resolved by Apier.
curl -H "Authorization: Bearer apier_live_<your_key>" \
  "https://www.apier.no/api/v1/company/991825827/context"

What developers build on it

Read an organisation's active Altinn 3 delegations and access packages to decide what your product is allowed to do on its behalf.
Submit MVA-melding through the Altinn 3 submitter with a dry-run validation pass first, and an HMAC-signed receipt on the live path.
Resolve who can legally act for an organisation — signaturrett, prokura, and the delegated System User scopes — before attempting a binding action.

FAQ

What is the difference between Altinn 2 and Altinn 3?: Altinn is Norway's shared platform for digital dialogue between businesses and the public sector. Altinn 2 is the older generation (SOAP services, role-based authorisation); Altinn 3 is the current generation (REST + the Instances API, access-package authorisation, and System Users for machine-to-machine access). DigDir decommissions Altinn 2 on 19 June 2026, after which Altinn 3 is the Altinn API.
Do I still need a System User and Maskinporten if I use Apier?: Your code does not. Apier's Auth Gateway owns the Maskinporten client-assertion flow and the Altinn 3 System User delegation handshake; your integration sends one Bearer API key. Each organisation grants your Apier account a System User delegation, and Apier resolves the right token and scopes at request time. Raw OAuth tokens never leave the gateway.
What happens to my Altinn 2 integration on 19 June 2026?: It stops working that day. Altinn 2 roles do not automatically carry over to Altinn 3 access packages, so each organisation needs a fresh Altinn 3 System User delegation. Apier exposes the role → access-package mapping as a zero-auth lookup at /api/v1/tools/altinn-migration; the deadline math is on /use-cases/altinn-migration.
Can I file to Altinn 3 through Apier?: Filing actions run through POST /api/v1/actions/execute. With ?dry_run=true the endpoint runs five preflight checks — company exists, System User authorised, scopes delegated, payload format valid, and a deadline-window guard that currently treats every action as unconstrained until the obligation-to-deadline mapping is enabled — and returns a structured outcome without submitting. The live path requires an Idempotency-Key, a single-use approval token, and an active delegation; mva_melding is the live-wired action type at v1, with the production Altinn 3 submission gated on Maskinporten production approval. Every successful submission returns an HMAC-signed receipt envelope.
How do I try the Altinn-backed endpoints without credentials?: Every Category B company endpoint has a zero-auth sandbox mirror under /api/v1/sandbox/public/ against the synthetic fixture org 999999999. The response shape matches production, so you can wire and test your client before provisioning a key. See the sandbox for copy-paste cURL.

Related developer pages

Maskinporten API — the machine-to-machine auth layer underneath Altinn 3.
Brønnøysund (BRREG) API — company lookup and the registry data Altinn authority resolves against.
Altinn for AI agents — the MCP server and deterministic cross-agency execution.
Documentation and the Apier home page.

Get started

The sandbox is curlable with no signup; the docs walk through the System User delegation flow and the live filing path.

Read the docs Try the sandbox