Apier.no

Company compliance summary

Retrieve a one-shot compliance summary for a Norwegian organisation by its 9-digit organisasjonsnummer. Your FIRST call when orienting against a company: one round-trip composes entity_type, nace_codes, mva_registered, data_tier, the full obligations[] catalogue, and the rolling deadlines[] calendar, all from one rule version. obligations[] is byte-identical to get_company_obligations; deadlines[] matches get_company_deadlines (tier_2 adds filing_status). Only { org_number } is exposed, so call

Obligations by entity type

Retrieve the universal obligation set for a Norwegian entity type — every regulatory obligation that applies by virtue of an entity BEING that organisational form, BEFORE per-company Tier-2 data is layered on. Use this to answer 'what does an AS owe?' or 'what are the baseline filings for an Enkeltpersonforetak?' without naming a specific company. Each obligation carries a tier_2_required boolean — true means the rule engine needs commercial data to know whether it applies to a SPECIFIC company,

Norges Bank exchange rate

Fetch the most recent Norges Bank exchange-rate reference for a currency against NOK — the canonical conversion benchmark Norwegian tax + accounting authorities accept for obligations in foreign currency (Årsregnskap, cross-border MVA, dividend reporting). The currency-of-record lookup; takes no Norwegian-company input. Returns the rate, the date it is valid for (weekday rates only; weekends / holidays return the prior business day's rate), and source attribution. Input: { base, quote, date? } —

Acting capacity for a person

Resolve every Norwegian regulatory action a person is currently authorised to perform on behalf of a specific organisation. Combines the actor's Altinn role assignments (DAGL, LEDE, MEDL, NESTL, INNH, REGN, REVI) with a conservative role-to-action map, returning the raw role list AND the derived action tokens an agent may pass to /v1/actions/execute (dry-run them first with the validate_action tool), each with a lovdata legal_reference. Inputs: an 11-digit fødselsnummer / D-nummer — HMAC-hashed;

Company profile (Brønnøysund)

Resolve a Norwegian organisasjonsnummer (9 digits) into a structured company profile from Brønnøysund Enhetsregisteret: display name, organisational form (AS / ENK / ASA …), NACE codes with descriptions, addresses, registration/dissolution dates, the `active` / `dissolved` status enum, the MVA-registered flag, and deduplicated person role CODES — never personal identifiers. Note the backing REST route is POST /api/v1/brreg/company-profile (org number in the JSON body), unlike the GET company sib

Authorisation snapshot

Return the authorisation snapshot for the calling consumer's delegation on a Norwegian organisation: the `status` enum (`full` / `partial` / `none`), `missing_scopes` (empty on `full`), `granted_scopes`, and the `delegation_chain` breadcrumbs. To check whether a SPECIFIC action is permitted, compare `granted_scopes` to the scopes it requires. Always runs against the calling consumer — no per-action or per-actor input at v1. Always a 200: with no delegation the verdict is `status: "none"`, never

Company registry facts

Retrieve the structured Brønnøysund identity slice for a Norwegian organisation by its 9-digit organisasjonsnummer: legal name, organisasjonsform (AS / ENK / NUF / ASA …), NACE codes, addresses, incorporation/dissolution dates, and the signaturrett / prokura role-code summary (never personal identifiers). Cache window 24 h. Choose this for the identity slice ONLY, without the compliance verdict; pair with get_company_obligations or get_company_deadlines for the regulatory layer. Failure modes: N

Company filing calendar

Compute the upcoming Norwegian regulatory filing calendar for a specific organisation, looking horizon_months ahead. One entry per (obligation, period) pair: a stable obligation_id matching get_company_obligations, the due_date as ISO 8601 in Europe/Oslo (DST-aware), the legal_reference, and recurrence/adjustment flags. Choose this for the calendar view — when does the next MVA / A-melding / Årsregnskap filing land? Inputs: { org_number (9 digits, MOD-11), horizon_months? (1–60) }. Failure modes

Company regulatory obligations

Evaluate the Apier Rulebook for a Norwegian organisation and return every applicable regulatory obligation with its current state and legal reference. One entry per obligation: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`), the lovdata legal_reference, the state enum (`filed` / `pending` / `in_progress` / `failed` / `overdue` / `unknown`), the bokmål description inherited byte-for-byte from the Rulebook (never re-translate it), and the freshness window. Deterministic, always against the c

Norwegian filing calendar

Compute the universal Norwegian regulatory filing calendar — the deadlines that apply to every Norwegian business of the covered categories (MVA, A-melding, Årsregnskap), independent of any specific organisation. One entry per (obligation, period) pair for a single Europe/Oslo calendar year: a stable obligation_id (e.g. `MVA_FILING_BIMONTHLY`), the due_date as ISO 8601 in Europe/Oslo (DST-aware), the lovdata legal_reference, a recurring flag, and a business_day_adjusted flag. Choose this tool fo

Validate a regulatory action (dry-run)

Run the Apier dry-run validator against a proposed regulatory action without producing ANY upstream side effect — no Maskinporten call, no Altinn / Skatteetaten / NAV submission. Use this BEFORE the live execute path to catch missing delegations and payload-shape errors at zero upstream cost. The verdict carries five prerequisite check slots (each pass / fail / skipped), the overall `valid` boolean, the DRY_RUN_DISCLAIMER (a pass is NOT a guarantee of upstream success), and the preview echo `wou

Explain a compliance error

Resolve a structured Apier compliance error code into a Norwegian-bokmål Explanation envelope: summary, bokmål why, ordered fix_steps, optional documentation link + legal_basis, and an optional handover block (who / where / what / why) for errors a human must resolve (e.g. AUTH_INSUFFICIENT_ROLE, AUTH_NO_DELEGATION, SCOPE_MISSING) — agent-resolvable errors ship `handover: null`. Accepts any code from the closed EXPLAINER_ERROR_CODES catalogue — pass whatever code an Apier endpoint returned in an

Search companies by name

Resolve a Norwegian company NAME to its 9-digit organisasjonsnummer. Use this as your FIRST call whenever you have a company's name but NOT its org_number — every other company tool requires the 9-digit number, and guessing a MOD-11-valid number risks hitting the wrong company. Searches Brønnøysund's public Enhetsregisteret and returns a token-efficient candidate list: up to ten matches, five fields each (name, org_number, org_form, municipality, registry status). Then call get_company_summary o

Company verification verdict

Get the deterministic verification verdict for a Norwegian organisation by its 9-digit organisasjonsnummer — a fast go / no-go trust check before acting on a company's behalf. Keyed ONLY off entity activity plus visible signing authority (signaturrett, prokura, or an ENK innehaver). `verification_status`: `pass` (active AND visible signing authority), `fail` (not active — konkurs, under avvikling, or oppløst), `unknown` (indeterminate or none visible — never a claimed absence; `warn` reserved).

Company signing-authority resolver

Answer "who can legally sign for this Norwegian company, and how?" before acting on its behalf. Given a 9-digit organisasjonsnummer it returns a deterministic signing-authority classification — `sole`, `joint`, `by_role`, `prokura_only`, `no_authority`, or `unknown` — from the open Fullmakttjenesten signing combinations plus the signaturrett / prokura role-holders. `kombinasjon_available: false` flags a degraded answer. No legal citation is asserted. Failure modes: NOT_FOUND, SCOPE_INSUFFICIENT

Company annual accounts snapshot

Current-snapshot read of a Norwegian company's annual accounts (årsregnskap) from the OPEN Regnskapsregisteret tier: `has_filed_annual_accounts` (tri-state — null means unknown, never a fabricated false), `last_accounts_year`, and that year's minimal `key_figures` (currency, presentation basis, totals). `currency` is always surfaced so figures are never silently read as NOK. Current-snapshot only — no multi-year history. A well-formed but unknown org_number returns 200 with `null`, not a 404. In

Company filing history (Altinn) + Apier audit trail

Reconcile a Norwegian company's Altinn 3 filing history against the filings YOUR consumer submitted through Apier. Given a 9-digit organisasjonsnummer it returns the org's Altinn filing instances (Mva-melding, A-melding, Skattemelding, …), each paired with its Apier audit record where one exists (`filed_via_apier` + `apier_record`). Cursor-paginated via { cursor } (pass back `pagination.next_cursor`) + { limit } (1–100, default 20); legacy { offset } still accepted (deprecated); no filings → 200

Query the cross-source change archive

Read Apier's cross-source change archive — detected created / updated / deleted events across the upstreams Apier polls (Brønnøysund ingestion plus the Altinn-schema, DigDir-policy, and Norges Bank pollers) so agents drive incremental sync instead of re-fetching whole entities. `observation_kind` separates cache warm-up rows from genuine transitions. Filter by { source, entity_type, entity_id, change_type } and a { from }–{ to } detected_at range. Queries WITHOUT entity_id withhold personal-fiel

Altinn 2 → Altinn 3 migration guidance

Discover the Altinn 3 equivalent of an Altinn 2 service or role code. The 19 June 2026 Altinn 2 deprecation deadline has passed, so this serves remediation for any integration still on Altinn 2. Pass { altinn2_code } (alphanumeric, 1–10 chars, e.g. A0208) for a single mapping, or omit it for the entire migration map. Every response carries the deprecation status computed in Europe/Oslo (deprecation_deadline, days_remaining — floored at 0, deadline_passed — now true). Each entry ships a `verified

Request a fullmakt (broker a systembruker delegation)

Broker a fullmakt — a legally-grounded, scoped, revocable company→agent authority delegated through an Altinn systembruker. The tool brokers the delegation, persists it, and binds the returned system_user_id write-once onto the principal (`pending` → `active`). The company's signing authority must approve the returned `delegation_url` before the delegation is usable. Non-empty `warnings[]` on a 201 means the delegation exists upstream but a local follow-up degraded - reconcile, never blind-retry

Check your fullmakt state for a company

Check your fullmakt state for a Norwegian company BEFORE acting on its behalf — the read leg of the Fullmakt Rails. Per agent principal of yours holding a live delegation there it returns: the bound system_user_id, whether the delegation is `active` or still `pending` signaturrett approval, the scopes carried, and the scopes still missing. `overall_status`: `full` (act now), `partial` (`fix_steps` names the blocker), or `none` — a VALID answer, not an error: 200 with empty `principals[]`, never

Revoke a fullmakt (retire a delegation + its principal)

Revoke a fullmakt — withdraw an agent's delegated authority for a Norwegian company and retire the agent principal (broker with request_fullmakt, inspect with check_fullmakt). Given ONLY the agent_principal_id (system_user_id and org_number resolve server-side from the write-once binding, so a client cannot redirect the revoke), Apier revokes the bound delegation and flips the principal to terminal `revoked` — never resurrected; create a new principal to act again. LOCAL revocation is authoritat

Apier price list (keyless)

Call this BEFORE metered work to check per-call cost and whether billing enforcement is live. Keyless: executes WITHOUT an API key, so an agent can price a workflow before it holds any credential. Returns the machine-readable price list: every credit-metered REST endpoint with its MCP tool name and cost in whole øre (always an integer), the enforcement.live flag (while false nothing is debited and a 402 is impossible), the 402 INSUFFICIENT_CREDITS recovery-contract field list, the top-up bounds

Own prepaid credit balance

Call this BEFORE a batch of metered calls to confirm the calling key's prepaid credit balance covers it, and AFTER a 402 INSUFFICIENT_CREDITS + human top-up to verify the funds landed. The balance is ALWAYS the authenticated key's own — no parameters, so reading another key's balance is structurally impossible. Returns api_key_id (non-secret UUID), balance_ore (whole øre, always an integer), currency (NOK), updated_at (null = never topped up = balance 0), and top_up_url (hand it to a human; agen

Redeem an owner-issued key-issuance token (keyless)

Convert an owner-issued key-issuance token into your own API key — the headless onboarding step for an agent that holds no credential yet. Keyless: the one-time token IS the credential. Minting and revocation are dashboard-only by design, so an agent can never self-issue authority. Redemption is strictly SINGLE-USE and atomic: on success (201) the token is consumed and the result carries {id, name, scopes, created_at, plaintext_key} — returned EXACTLY ONCE; store it immediately. Failure modes: a