Developer API

Maskinporten API

Norwegian machine-to-machine auth — without owning the certificate, the JWT signing, and the key-rotation lifecycle.

The ceremony before your first authenticated call

Getting a single Maskinporten token the conventional way is a multi-step setup, and the tokens expire:

• Certificate and client. Buy a virksomhetssertifikat from Buypass or Commfides, onboard through Samarbeidsportalen, and register a Maskinporten client with an RSA keypair.
• JWK and the signed assertion. Upload the public key as a JWK, then build and RS256-sign a JWT client-assertion on every token request, with the right issuer, audience, scope, and expiry claims.
• Scope grants and rotation. Request each API scope, keep the test and production environments separate, refresh tokens before they expire, and rotate the signing key on schedule. A clock-skew or audience mistake fails the exchange silently.

The full flow — and the ten pitfalls that each cost a day — is written up in the Maskinporten guide for developers.

Apier brokers the token

Apier holds the enterprise certificate and the Maskinporten client at the Auth Gateway. Your integration authenticates to Apier with one Bearer API key; the gateway presents the signed JWT client-assertion to Maskinporten, caches the resulting token for its lifetime, refreshes before expiry, and rotates the signing key on its own schedule. The raw OAuth token is never returned to your code and never logged — only the timestamp, scope, and success or failure are recorded.

• No keypair, no JWK, no assertion. You never generate a key, upload a JWK, or sign a JWT. The certificate lifecycle is the gateway's problem.
• Scopes mapped at the gateway. Your API key carries Apier-level scopes (read:brreg, read:altinn, read:actions, and so on); the underlying Maskinporten scope grants for each upstream are resolved for you.
• The same broker for every upstream. The token that authorises an Altinn 3 filing and the token that reads a Skatteetaten MVA-melding both come from the same brokered Maskinporten client — you integrate once.

What a call looks like

The difference is what is absent: there is no Maskinporten token in the request, because Apier obtained it for you.

# One Bearer API key. No virksomhetssertifikat, no JWK, no signed
# JWT client-assertion, no Maskinporten token in your code — Apier
# brokers all of that at the gateway.
curl -H "Authorization: Bearer apier_live_<your_key>" \
  "https://www.apier.no/api/v1/company/991825827/obligations"

# No key at all — zero-auth sandbox against synthetic org 999999999.
curl https://www.apier.no/api/v1/sandbox/public/company/999999999/obligations

Where the brokered token does the work

• Read Skatteetaten Tier 2 data (MVA-register, MVA-meldinger, skatteoppgjør) without standing up the three Maskinporten scope grants yourself.
• Authorise an Altinn 3 System User filing — the binding action still requires an approval token, but the Maskinporten leg is already handled.
• Ship a Norwegian-government integration in a product that onboards many customers, without a certificate-and-rotation project per customer.

FAQ

What is Maskinporten?

Maskinporten is Norway's OAuth2-based machine-to-machine authorization server, operated by DigDir. Norwegian government APIs require a Maskinporten access token, obtained by presenting a signed JWT client-assertion backed by an enterprise certificate (virksomhetssertifikat). It is the auth layer underneath most Norwegian public-sector machine integrations.

Do I need a virksomhetssertifikat to use Apier?

No. Apier holds the enterprise certificate and the Maskinporten client at the gateway. Your integration authenticates to Apier with one Bearer API key; Apier presents the signed JWT client-assertion to Maskinporten, caches the token, and rotates the signing key on its own schedule. You never generate a keypair, upload a JWK, or sign an assertion.

How does Apier handle token lifecycle and key rotation?

The Auth Gateway requests Maskinporten tokens via the JWT client-credentials grant, caches them for their lifetime, and refreshes before expiry. Signing keys rotate at the gateway with no change on your side. Tokens are never logged and never returned to your code — only the timestamp, scope, and success or failure are recorded.

Which Maskinporten scopes does Apier use?

Apier requests the scopes for the upstreams it brokers — for example Skatteetaten's skatteetaten:mva-register-read, skatteetaten:mva-melding-list-read, and skatteetaten:skatteoppgjor-read for the Tier 2 tax surface, plus the Altinn scopes that back the System User delegation flow. Your API key carries Apier-level scopes; the underlying Maskinporten mapping is handled at the gateway.

I want to run the Maskinporten flow myself — where is the deep guide?

The Maskinporten guide for developers walks through the raw flow end to end: virksomhetssertifikat, JWK upload, the JWT client-credentials exchange, System Users, and the ten pitfalls that each cost a day. This page is the value-prop layer above it.

Related developer pages

• Altinn API — the Altinn 3 surface the brokered token authorises against.
• Altinn for AI agents — the MCP server over the same brokered auth.
• Maskinporten guide for developers — the deep how-to if you want to run the flow yourself.
• Documentation and the Apier home page.

Get started

The sandbox needs no credentials at all; the docs cover the scopes your API key carries and how the gateway maps them onto Maskinporten.