Authenticating against the Apier API

Apier has three auth modes: none (Category A public infrastructure — obligations templates, deadlines, tools, capabilities), api_key (a consumer Bearer key, required for company data even on the Free tier), and admin_api_key (operator secret). Underneath, government authentication (Maskinporten, Altinn) is held server-side by Apier and never exposed to the caller.

Jurisdiction: Norway · Verified against Apier as of 2026-07-18

The three auth modes

Category A public-infrastructure endpoints (public obligations/deadlines, agent tools, the capabilities manifest) take no Authorization header at all and are rate-limited softly per IP — they exist for discoverability. Category B company-data endpoints require a consumer API key in the standard Authorization: Bearer header on every tier, because the records carry personal-adjacent data (board members, signaturrett, prokura). Operator endpoints use a separate admin secret and cannot be called with a consumer key.

API keys

Keys are presented as Authorization: Bearer apr_test_<your_key_here> (test) or the corresponding live prefix. Server-side they are stored only as SHA-256 hashes, never plaintext. A consumer can hold at most 3 active keys, which enables zero-downtime rotation: create the new key, cut traffic over, then revoke the old one. Rate limits apply per key, not per IP.

Scopes

Every key carries a scopes array (default read:*). The assignable vocabulary is read:brreg, read:altinn, read:digdir, read:norgesbank, read:changes, read:actions, subscribe:webhooks, and admin:keys; the action-segment wildcard read:* grants any read scope. Write prefixes (write:*, act:*, delegate:*) are reserved and not assignable at v1 — an agent's key can never approve its own binding writes. The capabilities endpoint exposes the assignable scopes for discovery.

Government auth stays server-side

The Maskinporten client, virksomhetssertifikat, JWS signing, token caching, and Altinn System User round-trips are all held by Apier. The consumer's API key is the only credential an agent manages; delegation state is checked through the permissions and acting-capacity endpoints.

Use cases

Choose the right auth mode for an integration: start keyless on Category A, add a key for company data
Rotate a key with zero downtime using the max-3-active-keys overlap
Scope keys to least privilege (e.g. read:brreg only) for a verification-only agent

Requirements

Nothing for Category A public endpoints
A registered consumer and an API key for Category B company data (all tiers including Free)
The appropriate scope on the key for each endpoint family

Authentication

Method: api_key · Scopes: read:*

This topic describes the auth model itself. Keys are minted and revoked via the account key endpoints; scope checks write an audit row on every evaluation.

Common errors

AUTH_MISSING
No usable Authorization header reached the API. A malformed Bearer value (whitespace, line breaks, paste artifacts) is stripped at the HTTP layer per RFC 7230 and surfaces as this code rather than a format error.
Fix: Send Authorization: Bearer <key> as a single clean line; validate locally that the key file is well-formed before use.
SCOPE_MISSING
The key is valid but lacks the scope the endpoint requires.
Fix: Mint or update a key carrying the required scope (e.g. read:brreg) and retry.
RATE_LIMIT_EXCEEDED
The per-key tier rate limit was hit.
Fix: Back off and retry after the Retry-After header's delay, or upgrade the tier.

Related APIs

Capability ids — resolve each against the machine-readable manifest at /api/v1/capabilities for the endpoint, auth mode, and tier.

admin.keys.create
admin.keys.list
admin.keys.revoke
auth.permissions

Related MCP tools

Registered tools on the Apier MCP server.

get_public_obligations
get_public_deadlines
explain_compliance_error
get_exchange_rate