Apier is a Norwegian company authority API: machine-verifiable company status, roles and coded signing authority. It gives an AI agent sourced, timestamped facts about a Norwegian company and its signing authority exactly as Brønnøysundregistrene hold it, uninterpreted, with obligations and deadlines as a supporting layer. It does not resell company data; every answer carries its source, the time it was read and, on request, a signed receipt.

Which Norwegian registers and systems does Apier read?

Brønnøysundregistrene for company and role data, including signaturrett and prokura from Fullmakttjenesten, the open Regnskapsregisteret for filed annual accounts, Norges Bank for exchange rates (a public tool endpoint) and Lovdata for law-text monitoring. Apier does not read Altinn 3 or Altinn Autorisasjon, holds no Maskinporten access on a customer's behalf, and does not submit anything to government. The current state of every capability is published at /docs/capability-status.

Is Apier a government service?

No. Apier is an independent private service operated by Grov Digital, not a public agency, and not endorsed by one. It reads public registry data under the Norwegian licence for public data reuse (NLOD); it does not act for companies in Altinn and does not read Altinn Autorisasjon. If you need the authoritative source itself rather than a normalised answer, go to Brønnøysundregistrene, Altinn, or Skatteetaten directly.

How does an AI agent authenticate, and how is that different from a person signing in?

An agent sends an API key as an Authorization: Bearer header. Keys are stored only as SHA-256 hashes, never in plaintext, and rate limits apply per key rather than per IP address. A person signs in to the dashboard with a magic link and a session cookie; there is no password. Some surfaces need no credential at all: the public endpoints, the capability and tool-discovery endpoints, and seven MCP tools are deliberately keyless so an agent can evaluate Apier before it has an account.

What happens when a Norwegian government API is down or times out?

Every upstream call runs through a reliability layer: a circuit breaker skips an upstream already known to be failing, transient failures are retried with exponential backoff and jitter, and a cooperative deadline stops a hung upstream from hanging your request. If the call still fails you get a structured error (a stable error_code, a plain-language explanation, and whether retrying the identical call is safe), never a partial or guessed answer. Apier does not substitute a default for missing government data.

What does the sandbox prove, and what does it not prove?

The sandbox proves the shape of your integration: request and response format, the structured-error envelope, idempotency, and how your agent recovers from failure, including failures you trigger on purpose with the simulate_error parameter. It proves nothing about your government access. Sandbox requests never reach Altinn, Maskinporten, Brønnøysund, Skatteetaten, or NAV; every answer comes from synthetic fixtures, every response is marked is_sandbox in its _meta block, and nothing a sandbox call does ever leaves the system. Whether your production key and its scopes work against real register data, only the live path can tell you.

What language does Apier answer in?

The API contract, the field names, and the documentation are English. Error explanations come back in Norwegian bokmål (the language the Norwegian registers and agencies publish in) with English companion fields on the same response, so an English-language agent never has to translate them. Norwegian regulatory terms such as MVA, signaturrett, and årsregnskap are kept as proper nouns rather than translated; the glossary explains each one.

Is Apier open source, and can I self-host it?

The service itself is hosted; there is no self-host distribution, because what you are buying is the maintained rulebook and the government credentials behind it, neither of which ships in a container. Published openly: the full API contract at /openapi.json, the MCP server package on npm, and the AVERT specification the execution model follows. Client SDK availability is tracked on /docs/capability-status.

What happens to my integration when a Norwegian rule changes?

Rules are stored as versioned data rather than code, so a rule change is a data update, not a deploy. Response contracts are append-only: new fields may appear at any time, but an existing field never changes meaning or type without a /v2 version bump. That means a rule change can alter which obligations apply to a company without ever changing the shape your code parses. Dated, user-visible changes are published on the changelog.

FAQ

Frequently asked questions

Apier is a Norwegian company authority API: machine-verifiable company status, roles and coded signing authority. It tells an AI agent whether a company is real and active and who the register says may sign for it, uninterpreted, with source and time on every answer; obligations and deadlines come with it.

About Apier

What is Apier?: Apier is a Norwegian company authority API: machine-verifiable company status, roles and coded signing authority. It gives an AI agent sourced, timestamped facts about a Norwegian company and its signing authority exactly as Brønnøysundregistrene hold it, uninterpreted, with obligations and deadlines as a supporting layer. It does not resell company data; every answer carries its source, the time it was read and, on request, a signed receipt.
Which Norwegian registers and systems does Apier read?: Brønnøysundregistrene for company and role data, including signaturrett and prokura from Fullmakttjenesten, the open Regnskapsregisteret for filed annual accounts, Norges Bank for exchange rates (a public tool endpoint) and Lovdata for law-text monitoring. Apier does not read Altinn 3 or Altinn Autorisasjon, holds no Maskinporten access on a customer's behalf, and does not submit anything to government. The current state of every capability is published at /docs/capability-status.
Is Apier a government service?: No. Apier is an independent private service operated by Grov Digital, not a public agency, and not endorsed by one. It reads public registry data under the Norwegian licence for public data reuse (NLOD); it does not act for companies in Altinn and does not read Altinn Autorisasjon. If you need the authoritative source itself rather than a normalised answer, go to Brønnøysundregistrene, Altinn, or Skatteetaten directly.
How does an AI agent authenticate, and how is that different from a person signing in?: An agent sends an API key as an Authorization: Bearer header. Keys are stored only as SHA-256 hashes, never in plaintext, and rate limits apply per key rather than per IP address. A person signs in to the dashboard with a magic link and a session cookie; there is no password. Some surfaces need no credential at all: the public endpoints, the capability and tool-discovery endpoints, and seven MCP tools are deliberately keyless so an agent can evaluate Apier before it has an account.
What happens when a Norwegian government API is down or times out?: Every upstream call runs through a reliability layer: a circuit breaker skips an upstream already known to be failing, transient failures are retried with exponential backoff and jitter, and a cooperative deadline stops a hung upstream from hanging your request. If the call still fails you get a structured error (a stable error_code, a plain-language explanation, and whether retrying the identical call is safe), never a partial or guessed answer. Apier does not substitute a default for missing government data.
What does the sandbox prove, and what does it not prove?: The sandbox proves the shape of your integration: request and response format, the structured-error envelope, idempotency, and how your agent recovers from failure, including failures you trigger on purpose with the simulate_error parameter. It proves nothing about your government access. Sandbox requests never reach Altinn, Maskinporten, Brønnøysund, Skatteetaten, or NAV; every answer comes from synthetic fixtures, every response is marked is_sandbox in its _meta block, and nothing a sandbox call does ever leaves the system. Whether your production key and its scopes work against real register data, only the live path can tell you. Try it at /sandbox.
What language does Apier answer in?: The API contract, the field names, and the documentation are English. Error explanations come back in Norwegian bokmål (the language the Norwegian registers and agencies publish in) with English companion fields on the same response, so an English-language agent never has to translate them. Norwegian regulatory terms such as MVA, signaturrett, and årsregnskap are kept as proper nouns rather than translated; the glossary explains each one.
Is Apier open source, and can I self-host it?: The service itself is hosted; there is no self-host distribution, because what you are buying is the maintained rulebook and the government credentials behind it, neither of which ships in a container. Published openly: the full API contract at /openapi.json, the MCP server package on npm, and the AVERT specification the execution model follows. Client SDK availability is tracked on /docs/capability-status.
What happens to my integration when a Norwegian rule changes?: Rules are stored as versioned data rather than code, so a rule change is a data update, not a deploy. Response contracts are append-only: new fields may appear at any time, but an existing field never changes meaning or type without a /v2 version bump. That means a rule change can alter which obligations apply to a company without ever changing the shape your code parses. Dated, user-visible changes are published on the changelog.

Questions answered elsewhere

Most questions are answered on the page that owns the subject, where the answer sits next to the detail it depends on. This page does not restate them.

Pricing, billing, and plan changes — What each tier includes, free access, and how billing works.
Data residency, subprocessors, and audit proof — Where data is hosted, who processes it, the human-approval step before binding writes, and how to prove what Apier did on your behalf.
Why Apier exists, data freshness, and who it is for — The thesis, whether data is live or cached, and who Apier is for.
Integration errors and how to fix them — Sandbox-versus-production keys, scope errors, withdrawn endpoints and rate limits.
Access for companies without a Norwegian registration — The cross-border sequence: what a foreign entity can read, and which gate blocks it first.
Company lookup, signature rights, and register search — Organisation numbers, Foretaksregisteret, prokura versus signaturrett, and what the registers return.
Verification, authority, accounts, and deadlines — The product pages, each with the questions specific to that capability.
The AVERT framework — Authorize, Validate, Execute, Receipt, Trail, and why traditional APIs fail for agents.
Connecting an MCP client — Server setup for Claude Desktop, Cursor, and other MCP clients.
Spørsmål på norsk — This page is English-only. The Norwegian surfaces carry their own questions in bokmål.

Frequently asked questions

About Apier

Questions answered elsewhere

Related reading