{"success":true,"data":{"service":"apier.no","version":"1","rulebook_version":"1.0.0","locale":"nb-NO","capabilities":[{"id":"public.deadlines","name_en":"Norwegian business deadline calendar","name_nb":"Norsk forretningsfristkalender","description_en":"Use this to get the canonical list of universal Norwegian business deadlines for a calendar year (MVA terminer, A-melding, skattemelding, årsregnskap). Deterministic and already adjusted forward through weekends and Norwegian public holidays.","description_nb":"Hent den kanoniske listen over universelle norske forretningsfrister for et gitt kalenderår (MVA-terminer, A-melding, skattemelding, årsregnskap). Deterministisk og allerede justert fremover for helger og norske helligdager.","endpoint":{"method":"GET","path":"/api/v1/public/deadlines"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getPublicDeadlines","example_request":"GET /api/v1/public/deadlines?year=2026","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"public.obligations","name_en":"Generic obligations by Norwegian entity type","name_nb":"Generelle forpliktelser per norsk selskapsform","description_en":"Use this to discover the universal obligations that apply to a given Norwegian entity type (AS, ENK, ANS, DA, NUF). Template layer only — call `getCompanyContext` plus `getPermissionState` when you need a per-company evaluation. Obligations with `tier_2_required: true` need a delegation before evaluation.","description_nb":"Oppdag de universelle forpliktelsene som gjelder for en gitt norsk selskapsform (AS, ENK, ANS, DA, NUF). Kun på malnivå: bruk `getCompanyContext` og `getPermissionState` for evaluering per selskap. Forpliktelser med `tier_2_required: true` krever delegering før evaluering.","endpoint":{"method":"GET","path":"/api/v1/public/obligations"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getPublicObligations","example_request":"GET /api/v1/public/obligations?entity_type=AS","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"public.company_status","name_en":"Bulk company status (up to 100 org numbers)","name_nb":"Selskapsstatus for mange selskaper (inntil 100 org.nr)","description_en":"Use this to resolve a whole portfolio in one call: up to 100 Norwegian organisation numbers → one row each with registry status, entity type, VAT registration, the raw distress flags (konkurs / under avvikling / under tvangsavvikling) and annual-accounts filing status. Per-row fault isolation — one unknown or unavailable company never fails the batch. Tier-1 NON-PERSONAL fields only: no role holders (signaturrett/prokura need an authenticated Category B call).","description_nb":"Slå opp en hel portefølje i ett kall: inntil 100 norske organisasjonsnummer → én rad per selskap med registerstatus, selskapsform, MVA-registrering, konkurs-/avviklingsflagg og status for levert årsregnskap. Feil på ett selskap velter aldri hele listen. Kun ikke-personlige Tier 1-felter. Rolleinnehavere (signaturrett/prokura) krever autentisert API-nøkkel.","endpoint":{"method":"GET","path":"/api/v1/public/company-status"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getPublicCompanyStatus","example_request":"GET /api/v1/public/company-status?org_numbers=923609016,999999999","data_sources":["brreg"],"freshness":"cached","status":"live"},{"id":"public.anchors","name_en":"Published Merkle anchors over the snapshot archive","name_nb":"Publiserte Merkle-ankere over arkivet","description_en":"Use this to fetch the daily Merkle roots that anchor Apier's append-only company snapshot archive: one root per UTC day, externally timestamped (RFC 3161) when available. This is tamper-evidence infrastructure — verify that archived history has not been rewritten — not company data; the surface carries derived hash material, dates and counts only, never personal data or snapshot payloads.","description_nb":"Hent de daglige Merkle-røttene som forankrer Apiers arkiv over selskapstilstander, som bare kan utvides: én rot per UTC-dag, med eksternt RFC 3161-tidsstempel når tilgjengelig. Dette er infrastruktur for å oppdage manipulasjon, ikke selskapsdata: verifiser at arkivert historikk ikke er skrevet om. Flaten inneholder kun avledet hashmateriale, datoer og antall, aldri persondata.","endpoint":{"method":"GET","path":"/api/v1/public/anchors"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getPublicAnchors","example_request":"GET /api/v1/public/anchors?limit=7","data_sources":["internal-supabase"],"freshness":"cached","status":"live"},{"id":"tools.exchange_rate","name_en":"Norges Bank NOK exchange rate","name_nb":"Valutakurs fra Norges Bank","description_en":"Use this to fetch the official NOK exchange rate for a currency and optional date. Weekends / holidays / pre-publication today fall back to the most recent prior business day; `data.date` is the actual publication date, `data.requested_date` is what you asked for.","description_nb":"Hent offisiell NOK-kurs fra Norges Bank for en valuta og en valgfri dato. Helger, helligdager og før publisering i dag faller tilbake til siste foregående virkedag; `data.date` er den faktiske publiseringsdatoen, `data.requested_date` er det du spurte om.","endpoint":{"method":"GET","path":"/api/v1/tools/exchange-rate"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getExchangeRate","example_request":"GET /api/v1/tools/exchange-rate?currency=EUR&date=2026-04-10","data_sources":["norges-bank"],"freshness":"cached","status":"live"},{"id":"tools.altinn_migration","name_en":"Altinn 2 → Altinn 3 migration lookup","name_nb":"Altinn 2 → Altinn 3 migrasjonsoppslag","description_en":"Use this to 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 now serves migration remediation, not pre-deadline planning. Gate production migration actions on `verified === true`; unverified entries are convenience references only.","description_nb":"Finn Altinn 3-tilsvarende for en Altinn 2-tjeneste- eller rollekode. Utfasingsfristen 19. juni 2026 er passert, så dette tjener nå migrasjonsutbedring, ikke planlegging i forkant. Baser produksjonsmigreringer på `verified === true`; uverifiserte oppføringer er kun referanseinformasjon.","endpoint":{"method":"GET","path":"/api/v1/tools/altinn-migration"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getAltinnMigration","example_request":"GET /api/v1/tools/altinn-migration?altinn2_code=A0208","data_sources":["digdir","internal-static"],"freshness":"static","status":"live"},{"id":"tools.explain","name_en":"Compliance error explainer","name_nb":"Forklaring av etterlevelsesfeil","description_en":"Use this to turn a structured Apier `error_code` into a Norwegian-bokmål Explanation — a one-line summary, a why, ordered fix_steps, an optional documentation link + Lovdata legal_basis, and (for errors a human must resolve) a handover block. Zero-auth; POST any error_code an Apier endpoint returned in an error envelope, plus optional `context` values (org_number, role, scope, field, upstream_system) the explainer interpolates into the text.","description_nb":"Gjør en strukturert Apier-`error_code` om til en forklaring på norsk bokmål: et sammendrag på én linje, en begrunnelse, ordnede fix_steps, en valgfri dokumentasjonslenke + Lovdata-hjemmel, og (for feil et menneske må løse) en overleveringsblokk. Uten autentisering; POST hvilken som helst error_code et Apier-endepunkt returnerte i en feilpakke, pluss valgfrie `context`-plassholdere (org_number, role, scope, field, upstream_system) som forklareren setter inn i teksten.","endpoint":{"method":"POST","path":"/api/v1/explain"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"explainComplianceError","example_request":"curl -X POST -H 'Content-Type: application/json' -d '{\"error_code\":\"VALIDATION_FAILED\"}' https://www.apier.no/api/v1/explain","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"company.context","name_en":"Company context (Tier 1 + Tier 2)","name_nb":"Selskapskontekst (Tier 1 + Tier 2)","description_en":"Use this as the canonical read on a Norwegian company: Tier 1 Brønnøysund fields plus the gated Tier 2 commercial metrics (employee count, turnover, balance-sheet total) when the consumer has an active delegation. Response `data.data_tier` tells you which tier was served; `_meta.served_from` distinguishes cache vs live. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Kanonisk oppslag på et norsk selskap: Tier 1 Brønnøysund-felter og de lukkede Tier 2 kommersielle metrikkene (antall ansatte, omsetning, balansesum) når konsumenten har en aktiv delegering. `data.data_tier` viser hvilket nivå som ble levert; `_meta.served_from` viser om svaret kom fra buffer eller ble hentet direkte. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/context"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyContext","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/context","data_sources":["brreg","internal-supabase"],"freshness":"cached","status":"live"},{"id":"company.verify","name_en":"Company verification verdict","name_nb":"Selskapsverifisering","description_en":"Use this for a fast go / no-go trust check on a Norwegian company before acting on its behalf. Deterministic verdict reduced from the same Tier 1 Brønnøysund data as `getCompanyContext` — no separate fetch. Computes seven live signals: `is_active` (registered status), `has_signing_authority_defined` (a signaturrett, prokura, or innehaver holder is visible in the open role data; `null` when nothing is visible — the register routinely omits signing arrangements, so absent data is unknown, never a claimed absence), `not_bankrupt` / `not_under_dissolution` / `not_forcibly_dissolved` (each derived by inverting a raw BRREG distress flag — `not_bankrupt: true` means `konkurs` is false; tri-state with independent per-flag parsing so co-occurring conditions are preserved), `mva_registered` (Tier-1 VAT status), and `has_filed_annual_accounts` (open Regnskapsregisteret filing status — `true` = annual accounts on file, `false` = the register authoritatively reports none, `null` = unknown / open tier does not cover the entity, never fabricated). `pass` = active with visible signing authority; `fail` = not active; `unknown` = status indeterminate, or active with no signing authority visible; `warn` is reserved in the contract and not emitted today. All transparency signals (distress, MVA, filing) never change the verdict; any signal stays `null` when its open-registry datum is genuinely unknown. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne for en rask tillitssjekk (bestått / feilet / ukjent) på et norsk selskap før du handler på dets vegne. Deterministisk verdikt utledet fra de samme Tier 1 Brønnøysund-dataene som `getCompanyContext`, uten separat henting. Beregner sju aktive signaler: `is_active` (registreringsstatus), `has_signing_authority_defined` (signaturrett, prokura eller innehaver er synlig i de åpne rolledataene; `null` når ingenting er synlig: registeret utelater ofte signaturforhold, så fravær av data er ukjent, aldri en påstått mangel), `not_bankrupt` / `not_under_dissolution` / `not_forcibly_dissolved` (hver utledet ved inversjon av et rått BRREG-statusflagg: `not_bankrupt: true` betyr at `konkurs` er usann; tre mulige verdier med uavhengig tolkning per flagg, slik at samtidige betingelser bevares), `mva_registered` (Tier-1 MVA-status) og `has_filed_annual_accounts` (innleveringsstatus fra åpent Regnskapsregister: `true` = årsregnskap innlevert, `false` = registeret melder autoritativt at ingen er innlevert, `null` = ukjent / den åpne tjenesten dekker ikke enheten, aldri fabrikkert). `pass` = aktiv med synlig signaturrett, prokura eller innehaver; `fail` = ikke aktiv; `unknown` = ubestemmelig status, eller aktiv uten synlig signaturforhold; `warn` er reservert i kontrakten og utstedes ikke i dag. Alle åpenhetssignalene (konkurs, MVA, innlevering) endrer aldri verdiktet; et signal forblir `null` når kildedataene er reelt ukjente. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/verify"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyVerification","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/verify","data_sources":["brreg","internal-supabase"],"freshness":"cached","status":"live"},{"id":"company.snapshot","name_en":"Unified company snapshot","name_nb":"Samlet øyeblikksbilde av selskapet","description_en":"Use this to orient on a Norwegian company in ONE round-trip instead of chaining getCompanyVerification, getCompanyAuthority, and getCompanyContext. Returns a single normalized object composing five sub-sections from the SAME handlers those endpoints use — no new government access: `verify` (the deterministic pass/fail/unknown trust verdict + its seven signals), `roles` (the signing-authority classification — sole / joint / by_role / prokura_only / no_authority / unknown — plus the signaturrett & prokura holders), `vat` (the Tier-1 BRREG mva_registered status, tri-state), `employer` (NAV Aa-registeret employment presence — `available: false` with a reason when the caller has no NAV delegation), and `risk` (a transparency-only `clear` / `elevated` / `unknown` level reduced from the BRREG distress signals — konkurs / avvikling / tvangsavvikling — NOT a credit score). Partial-failure tolerant: if one sub-source can't be composed it degrades to `{ status: \"degraded\", error }` while the other four stay populated and the call still returns 200; a non-existent org returns 404 and a BRREG outage with no cache returns 503. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne for å orientere deg om et norsk selskap i ÉN forespørsel i stedet for å kjede getCompanyVerification, getCompanyAuthority og getCompanyContext. Returnerer ett normalisert objekt som setter sammen fem deler fra de SAMME håndtererne disse endepunktene bruker, uten ny offentlig tilgang: `verify` (det deterministiske verdiktet bestått/feilet/ukjent + de sju signalene), `roles` (signaturklassifiseringen sole / joint / by_role / prokura_only / no_authority / unknown, samt innehaverne av signaturrett og prokura), `vat` (BRREG-statusen mva_registered på Tier 1, tre mulige verdier), `employer` (arbeidsgiverforhold fra NAV Aa-registeret, med `available: false` og en årsak når kalleren mangler NAV-delegering) og `risk` (et åpenhetsnivå `clear` / `elevated` / `unknown` utledet av BRREG-statusflaggene konkurs / avvikling / tvangsavvikling, IKKE en kredittscore). Toleranse for delvis feil: hvis én delkilde ikke kan settes sammen, degraderes den til `{ status: \"degraded\", error }` mens de fire andre forblir fylt ut og kallet fortsatt returnerer 200; et ikke-eksisterende organisasjonsnummer gir 404 og et BRREG-avbrudd uten buffer gir 503. Krever en API-nøkkel (Bearer) med scopet `read:brreg`.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/snapshot"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanySnapshot","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/snapshot","data_sources":["brreg","nav","internal-supabase"],"freshness":"cached","status":"live"},{"id":"company.accounts","name_en":"Company annual accounts snapshot","name_nb":"Selskapets årsregnskap (øyeblikksbilde)","description_en":"Use this for a current-snapshot read of a Norwegian company's annual accounts from the OPEN Regnskapsregisteret tier: `has_filed_annual_accounts` (tri-state — `true` = at least one annual-accounts record on file, `false` = the register authoritatively reports none for a covered entity, `null` = unknown / the open tier does not cover the entity, e.g. banks & insurers filing via a separate oppstillingsplan), `last_accounts_year` (most-recent accounting year, Europe/Oslo), and that year's minimal `key_figures` (currency, presentation basis, total assets, annual result, operating result, total equity + liabilities). `currency` is always surfaced so the monetary figures are never silently read as NOK (large issuers report in USD/EUR). v1 is current-snapshot only — no multi-year history, no closed/authenticated tier. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne for et øyeblikksbilde av et norsk selskaps årsregnskap fra det ÅPNE Regnskapsregisteret: `has_filed_annual_accounts` (tre mulige verdier: `true` = minst ett årsregnskap er innlevert, `false` = registeret melder autoritativt at ingen er innlevert for en dekket enhet, `null` = ukjent / den åpne tjenesten dekker ikke enheten, f.eks. banker og forsikringsselskap som leverer etter en egen oppstillingsplan), `last_accounts_year` (siste regnskapsår, Europe/Oslo) og det årets minimale `key_figures` (valuta, oppstillingsplan, sum eiendeler, årsresultat, driftsresultat, sum egenkapital og gjeld). `currency` vises alltid slik at beløpene aldri leses som NOK ved en feil (store utstedere rapporterer i USD/EUR). v1 gir kun et øyeblikksbilde: ingen flerårig historikk, ingen lukket/autentisert tjeneste. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/accounts"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyAccounts","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/accounts","data_sources":["brreg"],"freshness":"live","status":"live"},{"id":"company.authority","name_en":"Company signing-authority resolver","name_nb":"Selskapets signaturmyndighet","description_en":"Use this to answer \"who can legally sign for this Norwegian company, and how?\" before acting on its behalf. Returns a deterministic classification — `sole` (one role signs alone), `joint` (several roles must sign together), `by_role` (multiple alternative combinations; the path depends on role), `prokura_only` (no signaturrett, but prokura is defined), `no_authority` (neither registered), or `unknown` (the signing rule could not be determined). Normalised from the open Brønnøysund Fullmakttjenesten signing combinations (Brønnøysund applies the statutory signing rules server-side and returns `signeringsKombinasjon`; Apier buckets that output — it does NOT re-encode statute) combined with the already-loaded /roller holders. `data.combinations[]` carries each combination's Brønnøysund `kombinasjons_id` + human `description` + role codes; the role holders are listed once on `data.signaturrett_holders` / `data.prokura_holders` (not per-combination — the Fullmakt code vocabulary and the /roller label vocabulary do not align). `data.kombinasjon_available` is `false` when the signatur lookup was unreachable, in which case the classification degrades to the /roller holders plus any prokura combinations that could still be fetched. No legal citation is asserted. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne for å svare på «hvem kan signere lovlig for dette norske selskapet, og hvordan?» før du handler på dets vegne. Returnerer en deterministisk klassifisering: `sole` (én rolle signerer alene), `joint` (flere roller må signere i fellesskap), `by_role` (flere alternative kombinasjoner; avhenger av rolle), `prokura_only` (ingen signaturrett, men prokura er definert), `no_authority` (ingen av delene registrert) eller `unknown` (signeringsregelen kunne ikke fastslås). Normalisert fra de åpne signeringskombinasjonene i Brønnøysunds Fullmakttjeneste (Brønnøysund anvender de lovbestemte signeringsreglene på serversiden og returnerer `signeringsKombinasjon`; Apier kategoriserer resultatet uten å gjenskape lovteksten) kombinert med de allerede innlastede rolleinnehaverne fra /roller. `data.combinations[]` bærer hver kombinasjons `kombinasjons_id` + menneskelig `description` + rollekoder; rolleinnehaverne er oppført én gang på `data.signaturrett_holders` / `data.prokura_holders` (ikke per kombinasjon, fordi kodevokabularet i Fullmakt og etikettvokabularet i /roller ikke samsvarer). `data.kombinasjon_available` er `false` når signaturoppslaget var utilgjengelig, og da degraderes klassifiseringen til rolleinnehaverne pluss eventuelle prokurakombinasjoner som fortsatt kunne hentes. Ingen lovhjemmel påstås. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/authority"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyAuthority","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/authority","data_sources":["brreg","fullmakttjenesten"],"freshness":"live","status":"live"},{"id":"company.filing_history","name_en":"Company filing history (Altinn) paired with the Apier audit trail","name_nb":"Selskapets innsendingshistorikk (Altinn) sammenstilt med Apier-sporingsloggen","description_en":"Use this to reconcile a Norwegian company's Altinn 3 filing history against the filings YOUR consumer submitted through Apier, to find which filings match a submission in your own Apier audit trail. Returns the org's Altinn filing instances (Mva-melding, A-melding, Skattemelding, …) — form code, title, receiving agency, submitted_at (Europe/Oslo), status, and instance id — each PAIRED with its Apier audit-log entry where one exists: `filed_via_apier` is true with an `apier_record` (audit_log id + correlation_id) when a matching submission is found in your consumer's Apier audit trail, false when none is found; a false does not prove the filing was made directly in Altinn (it may have been submitted by another consumer, or the pairing may not have run). Pairing is best-effort (a transient audit-read failure degrades every filing to `filed_via_apier: false`, never failing the call). Offset-paginated (`limit` 1–100, `offset` ≥ 0); an org with no filings returns 200 with an empty list. MOCK-GATED build: deterministic synthetic fixtures today; the live Altinn path is pending the `altinn:instances.read` Maskinporten scope. Requires an API key (Bearer) with the read:altinn scope.","description_nb":"Bruk denne for å avstemme et norsk selskaps innsendingshistorikk i Altinn 3 mot innsendingene DIN konsument har levert via Apier, for å finne hvilke innsendinger som samsvarer med en innsending i din egen Apier-sporingslogg. Returnerer selskapets Altinn-innsendinger (Mva-melding, A-melding, Skattemelding, …) med skjemakode, tittel, mottakende etat, submitted_at (Europe/Oslo), status og instans-ID, hver sammenstilt med sin Apier-sporingsloggoppføring der den finnes: `filed_via_apier` er true med en `apier_record` (audit_log-id + correlation_id) når en samsvarende innsending finnes i din konsuments Apier-sporingslogg, false når ingen finnes; en false beviser ikke at innsendingen ble gjort direkte i Altinn (den kan være levert av en annen konsument, eller sammenstillingen kan ha uteblitt). Sammenstillingen er beste forsøk (en forbigående lesefeil mot sporingsloggen degraderer hver innsending til `filed_via_apier: false`, uten å feile kallet). Offset-paginert (`limit` 1–100, `offset` ≥ 0); et selskap uten innsendinger gir 200 med en tom liste. SIMULERT i dag: deterministiske, syntetiske testdata; den ekte Altinn-stien venter på Maskinporten-scopet `altinn:instances.read`. Krever en API-nøkkel (Bearer) med read:altinn-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/filing-history"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyFilingHistory","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/filing-history","data_sources":["altinn","internal-supabase"],"freshness":"live","status":"dry-run"},{"id":"company.search","name_en":"Company name search","name_nb":"Selskapssøk på navn","description_en":"Use this to resolve a Norwegian company NAME to its 9-digit organisasjonsnummer when you have a name but not a number. Searches Brønnøysund's open Enhetsregisteret by `navn` and returns up to 10 token-efficient candidates (name, org_number, org_form, municipality, registry status) — pick one, then call the other company endpoints with its org_number. Omit the legal form for a broader match; a zero-hit search returns NOT_FOUND with a broaden-the-name hint. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Slå opp et norsk selskaps 9-sifrede organisasjonsnummer ut fra NAVNET når du har navnet, men ikke nummeret. Søker i Brønnøysunds åpne Enhetsregister på `navn` og returnerer inntil 10 kompakte kandidater (navn, org_number, org_form, kommune, registerstatus). Velg én, og kall så de andre selskapsendepunktene med organisasjonsnummeret. Utelat selskapsformen for et bredere treff; null treff gir NOT_FOUND med et råd om å utvide søket. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/search"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"searchCompanies","example_request":"curl -H 'Authorization: Bearer <API_KEY>' 'https://www.apier.no/api/v1/company/search?name=Equinor'","data_sources":["brreg"],"freshness":"live","status":"live"},{"id":"company.profile","name_en":"Company profile (Brønnøysund)","name_nb":"Selskapsprofil (Brønnøysund)","description_en":"Use this to resolve a 9-digit organisasjonsnummer into a structured Brønnøysund Enhetsregisteret profile: display name, organisational form (AS / ENK / ASA …), NACE codes + descriptions, registered + business addresses, registration/dissolution dates, the agent-facing status enum (`active` / `dissolved`), the MVA-registered flag, and role codes for natural persons (codes only — never personal identifiers, per Rule 11 data minimisation). The backing route is POST (the org number goes in the JSON body). Tier 1 public data under NLOD; requires an API key (Bearer) with the read:brreg scope.","description_nb":"Slå opp et 9-sifret organisasjonsnummer og få en strukturert selskapsprofil fra Brønnøysund Enhetsregisteret: visningsnavn, organisasjonsform (AS / ENK / ASA …), NACE-koder + beskrivelser, forretnings- og postadresse, registrerings-/slettedato, statusverdien for agenter (`active` / `dissolved`), flagget for MVA-registrering og rollekoder for fysiske personer (kun koder, aldri personidentifikatorer, per Rule 11 dataminimering). Det bakenforliggende endepunktet er POST (organisasjonsnummeret ligger i JSON-kroppen). Tier 1 offentlige data under NLOD; krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"POST","path":"/api/v1/brreg/company-profile"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyProfile","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' -d '{\"org_number\":\"999999999\"}' https://www.apier.no/api/v1/brreg/company-profile","data_sources":["brreg"],"freshness":"cached","status":"live"},{"id":"company.summary","name_en":"Combined company obligations and deadlines summary","name_nb":"Samlet sammendrag av selskapets plikter og frister","description_en":"Use this as your FIRST call when orienting against a Norwegian company: one round-trip returns the entity_type, the served data tier, the full obligation catalogue the Universal Rulebook evaluates, and the rolling deadline calendar — all computed from one rule version and one company snapshot so downstream reasoning never has to reconcile drifting views. Composition only (`getCompanyContext` + the obligations evaluation + the deadline pipeline, plus a Tier-2 filing-status lookup that fills `deadlines[].filing_status` with verbatim `filed` / `overdue` signals). It deliberately does NOT return the full `/context` surface — no name, status, signaturrett, prokura, or role holders; call `getCompanyContext` for those. `data.data_tier` tells you which tier was served; `data.upgrade_path` is a Norwegian pointer at the Altinn delegation flow on tier_1 and null on tier_2. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne som ditt FØRSTE kall når du orienterer deg om et norsk selskap: ett kall returnerer entity_type, det leverte datanivået, hele forpliktelseskatalogen som Universal Rulebook evaluerer, og den rullerende fristkalenderen. Alt er beregnet fra én regelversjon og ett øyeblikksbilde av selskapet, slik at videre resonnement aldri må forene data som spriker. Kun komposisjon (`getCompanyContext` + forpliktelsesevalueringen + fristberegningen, pluss et Tier-2-oppslag av innleveringsstatus som fyller `deadlines[].filing_status` med ordrette `filed` / `overdue`-signaler). Den returnerer bevisst IKKE hele `/context`-flaten, verken navn, status, signaturrett, prokura eller rolleinnehavere; kall `getCompanyContext` for de feltene. `data.data_tier` viser hvilket nivå som ble levert; `data.upgrade_path` peker på Altinn-delegeringsflyten på tier_1 og er null på tier_2. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/summary"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanySummary","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/summary","data_sources":["brreg","internal-rulebook","internal-supabase"],"freshness":"cached","status":"live"},{"id":"company.obligations","name_en":"Company regulatory obligations","name_nb":"Selskapets regulatoriske forpliktelser","description_en":"Use this to retrieve every regulatory obligation the Universal Rulebook evaluates for a Norwegian company — one EvaluationResult per rule whose `entity_types[]` matches the company's entity_type, with all three verdicts side-by-side: `applicable` (every condition matched), `not_applicable` (at least one condition failed), and `insufficient_data` (a Tier-2 field the rule reads is null — surface a delegation path rather than guess yes/no). Deterministic and ordered `rule_id` ascending. Only rules whose citations are human-verified against Lovdata reach this endpoint. `data.data_tier` is tier_2 only when a Tier-2 delegation is active and the Registry has populated Tier-2 fields; tier_1 responses carry `insufficient_data` for every Tier-2-dependent rule plus a Norwegian `upgrade_path`. Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne for å hente hver regulatoriske forpliktelse som Universal Rulebook evaluerer for et norsk selskap: én EvaluationResult per regel hvis `entity_types[]` samsvarer med selskapets entity_type, med alle tre verdiktene side om side: `applicable` (alle betingelser oppfylt), `not_applicable` (minst én betingelse feilet) og `insufficient_data` (et Tier-2-felt regelen leser er null: vis en delegeringssti i stedet for å gjette ja/nei). Deterministisk og sortert `rule_id` stigende. Kun regler med kildehenvisninger som er menneskelig verifisert mot Lovdata når dette endepunktet. `data.data_tier` er tier_2 kun når en Tier-2-delegering er aktiv og Registeret har fylt Tier-2-feltene; tier_1-svar bærer `insufficient_data` for hver Tier-2-avhengig regel pluss en norsk `upgrade_path`. Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/obligations"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyObligations","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/obligations","data_sources":["brreg","internal-rulebook"],"freshness":"cached","status":"live"},{"id":"company.deadlines","name_en":"Company deadline calendar","name_nb":"Selskapets fristkalender","description_en":"Use this to get the concrete per-period deadline calendar for a Norwegian company: the Deadline Engine expands every applicable obligation into DeadlineEntry rows with Europe/Oslo offsets and weekend + Norwegian-holiday adjustment. The horizon is a rolling window anchored on `from_date` (defaults to today in Europe/Oslo) and extending `horizon_months` ahead (default 12, range 1-60). Each entry's `filing_status` is `upcoming` / `overdue` auto-derived from `due_at` vs `from_date` — this standalone endpoint does NOT inject a filing-status lookup, so call `getCompanySummary` on a Tier-2 delegation when you need verbatim `filed` signals. Obligations gated on a Tier-2 field short-circuit to `insufficient_data` and emit no entries until you delegate. Sorted `due_at` ascending (nulls last) and deterministic for a given (org, from_date, horizon_months). Requires an API key (Bearer) with the read:brreg scope.","description_nb":"Bruk denne for å hente den konkrete fristkalenderen per periode for et norsk selskap: Fristmotoren utvider hver gjeldende forpliktelse til DeadlineEntry-rader med Europe/Oslo-forskyvninger og justering for helger og norske helligdager. Horisonten er et rullerende vindu forankret på `from_date` (faller tilbake til i dag i Europe/Oslo) som strekker seg `horizon_months` fremover (standard 12, gyldig 1-60). Hver rads `filing_status` er `upcoming` / `overdue` automatisk utledet fra `due_at` mot `from_date`. Dette frittstående endepunktet gjør IKKE et oppslag av innleveringsstatus, så kall `getCompanySummary` med en Tier-2-delegering når du trenger ordrette `filed`-signaler. Forpliktelser som er betinget av et Tier-2-felt kortslutter til `insufficient_data` og gir ingen rader før du delegerer. Sortert `due_at` stigende (null sist) og deterministisk for en gitt (org, from_date, horizon_months). Krever en API-nøkkel (Bearer) med read:brreg-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/deadlines"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"getCompanyDeadlines","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/company/999999999/deadlines","data_sources":["brreg","internal-rulebook"],"freshness":"cached","status":"live"},{"id":"auth.permissions","name_en":"Check delegation status for an organisation","name_nb":"Sjekk delegasjonsstatus for en organisasjon","description_en":"Use this to poll whether the consumer already has an Altinn delegation for a given org. `data.status` is `full`, `partial`, or `none` — branch on it to decide whether to call `createSystemUserDelegation`.","description_nb":"Undersøk om konsumenten allerede har en Altinn-delegering for et gitt organisasjonsnummer. `data.status` er `full`, `partial` eller `none`. Bruk den til å avgjøre om `createSystemUserDelegation` må kalles.","endpoint":{"method":"GET","path":"/api/v1/auth/permissions/{org}"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"getPermissionState","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/auth/permissions/999999999","data_sources":["altinn","internal-supabase"],"freshness":"live","status":"dry-run"},{"id":"auth.acting_capacity","name_en":"Acting capacity for a person","name_nb":"Handleevne for en person","description_en":"Use this to resolve which Norwegian regulatory actions a person may currently perform on behalf of an organisation, combining their Altinn role assignments (DAGL, LEDE, MEDL, NESTL, INNH, REGN, REVI) with a conservative role-to-action map — each derived action token carries a lovdata legal_reference. The 11-digit fødselsnummer / D-nummer input is HMAC-SHA-256 hashed before any storage; the raw value is never persisted, logged, or returned (only `actor.fnr_hmac` echoes). Requires an API key (Bearer) with the read:altinn scope.","description_nb":"Finn ut hvilke norske regulatoriske handlinger en person kan utføre på vegne av et selskap akkurat nå, ved å kombinere personens Altinn-rolletildelinger (DAGL, LEDE, MEDL, NESTL, INNH, REGN, REVI) med en konservativ tilordning fra rolle til handling. Hvert utledet handlingstoken bærer en `legal_reference` til Lovdata. Det 11-sifrede fødselsnummeret / D-nummeret hashes med HMAC-SHA-256 før all lagring; råverdien lagres aldri, logges aldri og returneres aldri (kun `actor.fnr_hmac` returneres). Krever en API-nøkkel (Bearer) med read:altinn-scope.","endpoint":{"method":"POST","path":"/api/v1/altinn/list-acting-capacity"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"listActingCapacity","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' -d '{\"fnr\":\"12345678901\",\"org_number\":\"999999999\"}' https://www.apier.no/api/v1/altinn/list-acting-capacity","data_sources":["altinn"],"freshness":"cached","status":"dry-run"},{"id":"auth.delegate","name_en":"Create an Altinn 3 System User delegation","name_nb":"Opprett en Altinn 3 System User-delegering","description_en":"Use this when `getPermissionState` returns `none` or `partial`. Altinn returns a `delegation_url` that the company's signing authority must visit before the delegation becomes `active`. Supports Idempotency-Key.","description_nb":"Kall når `getPermissionState` returnerer `none` eller `partial`. Altinn returnerer en `delegation_url` som selskapets signaturberettigede må besøke før delegeringen blir `active`. Støtter Idempotency-Key.","endpoint":{"method":"POST","path":"/api/v1/auth/system-user/delegate"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"createSystemUserDelegation","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' -d '{\"org_number\":\"999999999\",\"scopes\":[\"altinn:authentication/systemuser.request.write\"]}' https://www.apier.no/api/v1/auth/system-user/delegate","data_sources":["altinn"],"freshness":"live","status":"gated"},{"id":"fullmakt.request","name_en":"Broker a fullmakt — bind an agent principal to a systembruker delegation","name_nb":"Formidle en fullmakt: knytt en agent-principal til en systembrukerdelegering","description_en":"Use this to turn an agent IDENTITY (an agent principal) into an ACTOR holding delegated authority for a specific Norwegian company. Brokers an Altinn systembruker delegation, persists it, and binds the returned `system_user_id` onto the principal (write-once; a 'pending' principal becomes 'active'). Altinn returns a `delegation_url` the company's signing authority must approve before the delegation becomes usable. A 201 with a non-empty `data.warnings` means the delegation EXISTS upstream but a local follow-up write degraded — reconcile, never blind-retry. A durable grant additionally returns a SIGNED delegation receipt (`data.signed_receipt`, HMAC-SHA256-v1) — Apier-verifiable proof of when the delegation was obtained, re-fetchable later via GET /api/v1/fullmakt/receipts. Receipt issuance is BEST-EFFORT: on rare degradation `signed_receipt` is null and `warnings` carries `receipt_generation_failed` — the grant itself still stands. Supports Idempotency-Key. Part of AGT-02 Fullmakt Rails; callable over the MCP server (/api/mcp) as the tool `request_fullmakt`.","description_nb":"Bruk denne for å gjøre en agent-IDENTITET (en agent-principal) om til en AKTØR med delegert myndighet for et bestemt norsk selskap. Formidler en systembrukerdelegering i Altinn, lagrer den, og knytter den returnerte `system_user_id` til principalen (skrives én gang; en 'pending' principal blir 'active'). Altinn returnerer en `delegation_url` som selskapets signaturberettigede må godkjenne før delegeringen kan brukes. En 201 med ikke-tom `data.warnings` betyr at delegeringen FINNES oppstrøms, men at en lokal oppfølgingsskriving feilet. Avstem, og gjenta aldri blindt. En varig tildeling returnerer i tillegg en SIGNERT delegeringskvittering (`data.signed_receipt`, HMAC-SHA256-v1): bevis som Apier kan verifisere på når fullmakten ble innhentet, og som senere kan hentes på nytt via GET /api/v1/fullmakt/receipts. Kvitteringsutstedelse skjer ETTER BESTE EVNE: ved sjelden degradering er `signed_receipt` null og `warnings` bærer `receipt_generation_failed`, men selve tildelingen står uansett. Støtter Idempotency-Key.","endpoint":{"method":"POST","path":"/api/v1/fullmakt/request"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"requestFullmaktDelegation","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Idempotency-Key: <UUID>' -H 'Content-Type: application/json' -d '{\"agent_principal_id\":\"11111111-1111-4111-8111-111111111111\",\"org_number\":\"999999999\",\"scopes\":[\"altinn:accessmanagement/authorizedparties.read\"]}' https://www.apier.no/api/v1/fullmakt/request","data_sources":["altinn"],"freshness":"live","status":"dry-run"},{"id":"fullmakt.status","name_en":"Check which of your agent principals hold fullmakt for a company","name_nb":"Sjekk hvilke av dine agent-principaler som har fullmakt for et selskap","description_en":"Use this BEFORE acting on behalf of a Norwegian company to find out whether you may act at all. Returns, per agent principal of yours holding a live delegation for that company: the bound `system_user_id`, whether the delegation is `active` or still `pending` the company's signing authority, the scopes it carries, and the scopes your tier's baseline still requires. `data.overall_status` is `full` (at least one principal is itself active AND holds an approved, scope-complete delegation — act now), `partial` (a delegation exists but something still blocks it: missing scopes, awaiting approval, or a principal that is suspended/revoked/not yet activated — `data.fix_steps` always names the specific blocker), or `none` (no principal of yours holds authority here). `none` is a valid answer, NOT an error: this endpoint returns 200 with an empty `data.principals` and Norwegian `data.fix_steps` pointing at POST /v1/fullmakt/request — never a 404. Reports the delegation state Apier RECORDED when it brokered the fullmakt; it is not a live Altinn decision, so the two can diverge if a delegation is revoked upstream without Apier observing it. Requires an API key (Bearer) with the read:altinn scope. Part of AGT-02 Fullmakt Rails; callable over the MCP server (/api/mcp) as the tool `check_fullmakt`.","description_nb":"Bruk denne FØR du handler på vegne av et norsk selskap, for å finne ut om du i det hele tatt har lov. Returnerer, per agent-principal du eier som har en aktiv delegering for selskapet: den tilknyttede `system_user_id`, om delegeringen er `active` eller fortsatt `pending` godkjenning fra signaturrett, hvilke scoper den bærer, og hvilke scoper nivået ditt fortsatt krever. `data.overall_status` er `full` (minst én principal er selv aktiv OG har en godkjent delegering som dekker alle nødvendige scoper, så du kan handle nå), `partial` (en delegering finnes, men noe blokkerer fortsatt: manglende scoper, venter på godkjenning, eller en principal som er suspendert/tilbakekalt/ikke aktivert ennå. `data.fix_steps` navngir alltid den konkrete blokkeringen) eller `none` (ingen av dine principaler har myndighet her). `none` er et gyldig svar, IKKE en feil: endepunktet returnerer 200 med tom `data.principals` og norske `data.fix_steps` som peker på POST /v1/fullmakt/request, aldri 404. Rapporterer delegeringstilstanden Apier REGISTRERTE da fullmakten ble formidlet; det er ikke en sanntidsavgjørelse fra Altinn, så de to kan avvike dersom en delegering tilbakekalles oppstrøms uten at Apier observerer det. Krever en API-nøkkel (Bearer) med read:altinn-scope.","endpoint":{"method":"GET","path":"/api/v1/fullmakt/{org}"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"getFullmaktState","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/fullmakt/999999999","data_sources":["altinn"],"freshness":"live","status":"dry-run"},{"id":"fullmakt.revoke","name_en":"Revoke a fullmakt — retire a delegation and its agent principal","name_nb":"Tilbakekall en fullmakt: avvikle en delegering og dens agent-principal","description_en":"Use this to withdraw an agent's delegated authority for a Norwegian company. Given the agent principal, Apier revokes the delegation bound to its systembruker (append-only: a status='revoked' marker row supersedes the original — no read or enforcement surface honours the delegation afterwards) and flips the principal to terminal 'revoked' (a revoked principal is never resurrected; create a new one to act again). Idempotent: revoking an already-revoked principal/delegation is a 200 no-op. `data.warnings` carries NAMED outcome tokens, each with its own meaning — `principal_revoke_failed` (the delegation IS revoked but the principal flip failed; re-inspect and retry), `delegation_not_found` (no live delegation existed behind the principal; the principal revocation itself proceeded), `upstream_revoke_unconfirmed` (the best-effort Altinn-side propagation returned no ack; expected while the upstream flow is pending live partner validation) — read the specific token rather than treating any non-empty array as a local failure. Apier's own gating honours the local revocation immediately. A fresh revocation additionally returns a SIGNED delegation receipt (`data.signed_receipt`, HMAC-SHA256-v1) — Apier-verifiable proof of when the authority ended, re-fetchable later via GET /api/v1/fullmakt/receipts. Receipt issuance is BEST-EFFORT: on rare degradation `signed_receipt` is null and `warnings` carries `receipt_generation_failed` — the revocation itself still stands. Supports Idempotency-Key. Part of AGT-02 Fullmakt Rails; callable over the MCP server (/api/mcp) as the tool `revoke_fullmakt`.","description_nb":"Bruk denne for å trekke tilbake en agents delegerte myndighet for et norsk selskap. Gitt agent-principalen tilbakekaller Apier delegeringen knyttet til dens systembruker (tabellen kan bare utvides: en markørrad med status='revoked' overstyrer originalen, og ingen lese- eller håndhevingsflate anerkjenner delegeringen etterpå) og setter principalen til terminal 'revoked' (en tilbakekalt principal gjenopprettes aldri; opprett en ny for å handle igjen). Idempotent: å tilbakekalle en allerede tilbakekalt principal/delegering gir 200 uten endring. `data.warnings` bærer NAVNGITTE utfallstoken med hver sin betydning: `principal_revoke_failed` (delegeringen ER tilbakekalt, men statusendringen på principalen feilet; undersøk og prøv igjen), `delegation_not_found` (ingen aktiv delegering fantes bak principalen; selve principal-tilbakekallingen gikk gjennom), `upstream_revoke_unconfirmed` (videreføringen til Altinn, som gjøres etter beste evne, ga ingen bekreftelse; forventet mens oppstrømsflyten venter på partnervalidering i produksjon). Les det konkrete tokenet i stedet for å tolke enhver ikke-tom liste som en lokal feil. Apiers egen tilgangsstyring anerkjenner den lokale tilbakekallingen umiddelbart. En fersk tilbakekalling returnerer i tillegg en SIGNERT delegeringskvittering (`data.signed_receipt`, HMAC-SHA256-v1): bevis som Apier kan verifisere på når myndigheten opphørte, og som senere kan hentes på nytt via GET /api/v1/fullmakt/receipts. Kvitteringsutstedelse skjer ETTER BESTE EVNE: ved sjelden degradering er `signed_receipt` null og `warnings` bærer `receipt_generation_failed`, men selve tilbakekallingen står uansett. Støtter Idempotency-Key.","endpoint":{"method":"POST","path":"/api/v1/fullmakt/revoke"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"revokeFullmaktDelegation","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Idempotency-Key: <UUID>' -H 'Content-Type: application/json' -d '{\"agent_principal_id\":\"11111111-1111-4111-8111-111111111111\",\"reason\":\"Engagement ended\"}' https://www.apier.no/api/v1/fullmakt/revoke","data_sources":["altinn"],"freshness":"live","status":"dry-run"},{"id":"fullmakt.receipts","name_en":"List your signed delegation receipts — proof of fullmakt lifecycle events","name_nb":"List dine signerte delegeringskvitteringer: bevis for hendelser i fullmaktens livssyklus","description_en":"Use this to retrieve the cryptographic proof of your fullmakt lifecycle events after the original response is gone. Each entry's `receipt` object is the COMPLETE signed delegation receipt (delegation_granted or delegation_revoked): every signed field plus the HMAC-SHA256-v1 `signature`, exactly as emitted by POST /api/v1/fullmakt/request or POST /api/v1/fullmakt/revoke — proof that at time T this consumer obtained or revoked a scoped delegation for org O under systembruker S. Keyset-paginated newest-first (`limit`, `before` + `before_id` as a tuple); only YOUR OWN receipts are listed.","description_nb":"Bruk denne for å hente det kryptografiske beviset for hendelsene i fullmaktenes livssyklus etter at det opprinnelige svaret er borte. Hver oppførings `receipt`-objekt er den KOMPLETTE signerte delegeringskvitteringen (delegation_granted eller delegation_revoked): alle signerte felter pluss HMAC-SHA256-v1-`signature`, nøyaktig slik den ble utstedt av POST /api/v1/fullmakt/request eller POST /api/v1/fullmakt/revoke. Det er bevis på at denne konsumenten på tidspunkt T innhentet eller tilbakekalte en avgrenset delegering for organisasjon O under systembruker S. Markørbasert paginering, nyeste først (`limit`, `before` + `before_id` som et par); kun DINE EGNE kvitteringer listes.","endpoint":{"method":"GET","path":"/api/v1/fullmakt/receipts"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"listFullmaktReceipts","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/fullmakt/receipts","data_sources":["altinn"],"freshness":"live","status":"dry-run"},{"id":"auth.approval_token","name_en":"Mint a single-use approval token for a high-risk action","name_nb":"Generer et godkjenningstoken til engangsbruk for en høyrisikohandling","description_en":"Use this ONLY after a human operator in the consumer's UI has explicitly confirmed the action. The plaintext token is returned exactly once and must be presented in `X-Approval-Token` on the subsequent write call — downstream endpoints treat it as proof-of-consent.","description_nb":"Kall kun etter at en menneskelig operatør i konsumentens UI eksplisitt har bekreftet handlingen. Klartekstverdien returneres nøyaktig én gang og må sendes i `X-Approval-Token` på det påfølgende skrivekallet. Endepunktene nedstrøms behandler det som samtykkebevis.","endpoint":{"method":"POST","path":"/api/v1/auth/approval-token"},"auth":"api_key","tier_minimum":"free","category":"auth","openapi_operation_id":"mintApprovalToken","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' -d '{\"org_number\":\"999999999\",\"action_id\":\"filing.submit\"}' https://www.apier.no/api/v1/auth/approval-token","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"company.audit","name_en":"Read consumer's own audit trail for a company","name_nb":"Les egen sporingslogg for en virksomhet","description_en":"Use this to read the slice of the immutable Sporingslogg (audit_log) that THIS consumer wrote against a single org_number — keyset-paginated, time-ordered, with optional filters on action / initiated_by / since / until. Cross-consumer visibility is structurally impossible: the auth boundary is consumer_id (resolved from your API key), and the URL org_number is a within-namespace filter. Each row carries correlation_id (joins to provenance_log / evaluation_snapshots / compliance_state_events from the same request), initiated_by (human / agent / cron / system / unknown), and schema_version. Sensitive keys in `details` are auto-redacted at write AND read time. Empty result returns 200 with `data: []` (NEVER 404 — that would leak existence across consumers). Requires API key with read:audit scope.","description_nb":"Les den delen av den uforanderlige Sporingsloggen (audit_log) som DENNE konsumenten har skrevet mot et bestemt organisasjonsnummer, med markørbasert paginering, sortert etter tid, med valgfrie filtre på action / initiated_by / since / until. Det er strukturelt umulig å se andre konsumenters rader: autentiseringsgrensen er consumer_id (utledet fra API-nøkkelen din), og URL-ens org_number er et filter innenfor ditt eget navnerom. Hver rad bærer correlation_id (forener med provenance_log / evaluation_snapshots / compliance_state_events fra samme forespørsel), initiated_by (human / agent / cron / system / unknown) og schema_version. Sensitive nøkler i `details` sladdes automatisk både ved skriving og lesing. Tomt resultat returnerer 200 med `data: []` (ALDRI 404, for det ville lekke eksistens på tvers av konsumenter). Krever API-nøkkel med read:audit-scope.","endpoint":{"method":"GET","path":"/api/v1/company/{org}/audit"},"auth":"api_key","tier_minimum":"free","category":"company-data","openapi_operation_id":"readCompanyAuditTrail","example_request":"curl -H 'Authorization: Bearer <API_KEY>' 'https://www.apier.no/api/v1/company/999999999/audit?limit=50&initiated_by=agent'","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"changes.query","name_en":"Query the cross-source change archive","name_nb":"Søk på endringsarkivet på tvers av kilder","description_en":"Paginated, filterable read over detected archive events — Brreg ingestion (PR-023b) plus the multi-source pollers for Altinn schemas and Norges Bank rates (PR-023c). The DigDir policy poller was retired in PR-MOAT-08 without ever emitting a row; `digdir` remains a valid (currently empty) source filter. NOT every row is a real-world change: each row carries a derived observation_kind separating first-time archive sightings (first_observation — Apier's cache warming up) from genuine observed transitions (value_change). Filterable by source / entity_type / entity_id / change_type / from–to date range. Queries WITHOUT entity_id return non-personal rows only (personal role-holder fields are org-scoped — supply entity_id; the response flags this via personal_fields_withheld). Cursor-paginated with HMAC-signed cursors so consumers can't tamper with keyset offsets. Requires API key with read:changes scope.","description_nb":"Paginert, filtrerbart oppslag mot endringsarkivet: innhenting fra Brreg (PR-023b) og innhenterne for Altinn-skjemaer og Norges Bank-kurser (PR-023c). Digdir-innhenteren for policydokumenter ble avviklet i PR-MOAT-08 uten noen gang å ha levert en rad; `digdir` er fortsatt et gyldig (men tomt) kildefilter. IKKE hver rad er en reell endring: hver rad bærer et avledet observation_kind som skiller første observasjon i arkivet (first_observation) fra en faktisk observert overgang (value_change). Filtrerbart på source / entity_type / entity_id / change_type / datointervall. Spørringer UTEN entity_id returnerer kun ikke-personlige rader (personfelter er avgrenset per organisasjon, så oppgi entity_id; svaret flagger dette via personal_fields_withheld). Markørbasert paginering med HMAC-signerte markører. Krever API-nøkkel med read:changes-scope.","endpoint":{"method":"GET","path":"/api/v1/changes"},"auth":"api_key","tier_minimum":"starter","category":"company-data","openapi_operation_id":"queryChanges","example_request":"curl -H 'Authorization: Bearer <API_KEY>' 'https://www.apier.no/api/v1/changes?source=brreg&entity_id=998877665&from=2026-01-01T00:00:00Z'","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"subscriptions.create","name_en":"Subscribe to change-archive deltas via webhook","name_nb":"Abonner på endringer i endringsarkivet via webhook","description_en":"Create a subscription that pushes filtered change-archive events to your webhook URL. Apier signs every delivery with HMAC-SHA256 over `<timestamp>.<body>` (Stripe-style). The plaintext webhook secret is returned ONCE on create — store it client-side. URLs are SSRF-validated at create AND at every delivery; private CIDRs / metadata-endpoint hosts / .local suffixes are rejected. Requires API key with subscribe:webhooks scope. The only v1 event type is accounts.updated (filter source=brreg, entity_type=annual_accounts).","description_nb":"Opprett et abonnement som sender filtrerte hendelser fra endringsarkivet til din webhook-URL. Apier signerer hver leveranse med HMAC-SHA256 over `<tidsstempel>.<kropp>` (samme mønster som Stripe). Hemmeligheten returneres i klartekst ÉN GANG ved opprettelse. Lagre den hos deg selv. URL-er SSRF-valideres ved opprettelse OG ved hver leveranse; private CIDR-er / metadataendepunkter / .local-suffikser avvises. Krever API-nøkkel med subscribe:webhooks-scope. Den eneste v1-hendelsestypen er accounts.updated (filter source=brreg, entity_type=annual_accounts).","endpoint":{"method":"POST","path":"/api/v1/subscriptions"},"auth":"api_key","tier_minimum":"professional","category":"company-data","openapi_operation_id":"createSubscription","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' -d '{\"webhook_url\":\"https://yourapp.example/hooks\",\"filter\":{\"source\":\"brreg\"}}' https://www.apier.no/api/v1/subscriptions","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"subscriptions.list","name_en":"List your active webhook subscriptions","name_nb":"Vis dine aktive webhook-abonnementer","description_en":"Lists active subscriptions belonging to the calling consumer. Secret material is NEVER returned — only metadata. Inactive subscriptions are not included.","description_nb":"Lister aktive abonnementer som tilhører den kallende konsumenten. Hemmeligheten returneres ALDRI, kun metadata. Inaktive abonnementer er ikke inkludert.","endpoint":{"method":"GET","path":"/api/v1/subscriptions"},"auth":"api_key","tier_minimum":"professional","category":"company-data","openapi_operation_id":"listSubscriptions","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/subscriptions","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"subscriptions.delete","name_en":"Delete a webhook subscription","name_nb":"Slett et webhook-abonnement","description_en":"Soft-deletes a subscription (active=false). Idempotent. Cross-consumer access returns 404 to prevent existence leaks.","description_nb":"Myk sletting av et abonnement (active=false). Idempotent. Tilgang på tvers av konsumenter returnerer 404 for å hindre eksistenslekkasje.","endpoint":{"method":"DELETE","path":"/api/v1/subscriptions/{id}"},"auth":"api_key","tier_minimum":"professional","category":"company-data","openapi_operation_id":"deleteSubscription","example_request":"curl -X DELETE -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/subscriptions/550e8400-e29b-41d4-a716-446655440000","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"admin.keys.create","name_en":"Create an API key for a consumer (admin)","name_nb":"Opprett en API-nøkkel for en konsument (admin)","description_en":"Operator-only — requires the ADMIN_API_KEY bearer secret. Returns the plaintext key exactly once; only the SHA-256 hash is stored. Maximum three active keys per consumer.","description_nb":"Kun operatør: krever ADMIN_API_KEY som Bearer-hemmelighet. Returnerer klartekstnøkkelen nøyaktig én gang; kun SHA-256-hashen lagres. Maksimalt tre aktive nøkler per konsument.","endpoint":{"method":"POST","path":"/api/v1/admin/keys"},"auth":"admin_api_key","tier_minimum":null,"category":"admin","openapi_operation_id":"createApiKey","example_request":"curl -X POST -H 'Authorization: Bearer <ADMIN_API_KEY>' -H 'Content-Type: application/json' -d '{\"consumer_id\":\"uuid...\"}' https://www.apier.no/api/v1/admin/keys","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"admin.keys.list","name_en":"List active API keys for a consumer (admin)","name_nb":"List aktive API-nøkler for en konsument (admin)","description_en":"Operator-only. Lists active (non-revoked) keys for a consumer. Never returns plaintext — only key metadata (id, label, created_at).","description_nb":"Kun operatør. Lister aktive (ikke tilbakekalte) nøkler for en konsument. Returnerer aldri klartekst, kun nøkkelmetadata (id, label, created_at).","endpoint":{"method":"GET","path":"/api/v1/admin/keys"},"auth":"admin_api_key","tier_minimum":null,"category":"admin","openapi_operation_id":"listApiKeys","example_request":"curl -H 'Authorization: Bearer <ADMIN_API_KEY>' 'https://www.apier.no/api/v1/admin/keys?consumer_id=<UUID>'","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"admin.keys.revoke","name_en":"Revoke an API key (admin)","name_nb":"Tilbakekall en API-nøkkel (admin)","description_en":"Operator-only. Soft-revokes a key by setting `is_revoked=true` and `revoked_at=now()`. Irreversible.","description_nb":"Kun operatør. Myk tilbakekalling av en nøkkel ved å sette `is_revoked=true` og `revoked_at=now()`. Irreversibel.","endpoint":{"method":"DELETE","path":"/api/v1/admin/keys/{id}"},"auth":"admin_api_key","tier_minimum":null,"category":"admin","openapi_operation_id":"revokeApiKey","example_request":"curl -X DELETE -H 'Authorization: Bearer <ADMIN_API_KEY>' https://www.apier.no/api/v1/admin/keys/<KEY_UUID>","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"discovery.recipes","name_en":"Human-readable workflow recipes page","name_nb":"Menneskelesbare oppskrifter for arbeidsflyter","description_en":"Use this as the human-readable counterpart to /workflows.json. SSR HTML page that renders one section per canonical workflow: intent, steps, failure modes, agent_instructions, and a copy-paste cURL example. Content is derived from the same manifest /workflows.json serves — update the manifest and this page updates with it. Not a JSON API; intended for developers and as a crawlable page for AI agents that prefer HTML.","description_nb":"Bruk denne som menneskelesbar motpart til /workflows.json. SSR HTML-side som viser én seksjon per kanoniske arbeidsflyt: intensjon, trinn, feilmoduser, agent_instructions og et cURL-eksempel du kan kopiere. Innholdet er avledet fra samme manifest som /workflows.json, så endringer i manifestet gjenspeiles her automatisk. Ikke et JSON-API; ment for utviklere og som en side som kan gjennomsøkes av AI-agenter som foretrekker HTML.","endpoint":{"method":"GET","path":"/recipes"},"auth":"none","tier_minimum":null,"category":"discovery","openapi_operation_id":"getRecipesPage","example_request":"curl https://www.apier.no/recipes","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"discovery.comparison.direct-integration","name_en":"Apier vs direct integration comparison","name_nb":"Apier mot direkteintegrasjon: sammenligning","description_en":"Use this to fetch the qualitative Apier-vs-direct-integration comparison matrix. Each dimension (authentication, delegation/authority, audit trail, legal grounding, error handling, deadline intelligence, cross-agency orchestration, maintenance burden, time-to-first-call) carries one factual statement per column. Machine-readable, not marketing — quantitative performance claims are intentionally absent until measured live telemetry exists, and the `methodology` + `source` fields state the comparison basis on the wire.","description_nb":"Hent den kvalitative matrisen som sammenligner Apier med å bygge direkteintegrasjonen mot offentlige API-er selv. Hver dimensjon har ett faktabasert utsagn per kolonne. Maskinlesbar, ikke markedsføring: kvantitative ytelsestall er bevisst utelatt til målt telemetri fra produksjon finnes, og feltene `methodology` + `source` oppgir sammenligningsgrunnlaget i selve svaret.","endpoint":{"method":"GET","path":"/api/v1/comparison/direct-integration"},"auth":"none","tier_minimum":null,"category":"discovery","openapi_operation_id":"getComparisonDirectIntegration","example_request":"curl https://www.apier.no/api/v1/comparison/direct-integration","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"actions.execute_dry_run","name_en":"Validate (dry-run) or submit (live) a filing action","name_nb":"Valider (prøveinnsending) eller send inn (i produksjon) en innleveringshandling","description_en":"Two discriminated behaviours on the same endpoint, selected by the `?dry_run=true` query parameter.\n\nDRY-RUN MODE (`?dry_run=true`) — validates a filing-action payload (mva_melding OR a_melding — both are accepted on dry-run) against five preflight checks WITHOUT submitting anything to Altinn / Skatteetaten / NAV. Returns 200 with a structured DryRunOutcome listing each check's pass/fail. The disclaimer reminds agents that a passing dry-run is NOT a guarantee of submission success.\n\nLIVE-EXECUTE MODE (?dry_run omitted or any value other than 'true') — when Maskinporten production approval is enabled, submits the filing to Altinn 3 (which routes to the Skatteetaten / NAV service owner). UNTIL THAT GATE CLEARS, the endpoint contract is shipped but the submitter is mock-backed (ALTINN_MODE=mock — the default; the per-integration switch per CLAUDE.md Rule 12, distinct from MASKINPORTEN_MODE which gates the Maskinporten auth layer): the route runs end-to-end through receipt signing + persistence + audit chain, but the upstream `altinn_receipt_id` is the deterministic SHA-256-derived MOCK-ALT-* value from the mock submitter. Production rollout requires Maskinporten production credentials + Skatteetaten MVA-melding service-owner approval + a live submitter implementation in src/lib/altinn/live-submitter.ts + DECISIONS.md sign-off (see DECISIONS.md PR-077 §1 for the full activation checklist). v1 supports mva_melding only on the LIVE path; a_melding live submission is gated on the live NAV integration and returns 403 PLAN_INSUFFICIENT in live mode (a_melding dry-run validation IS supported — only live submission is blocked).\n\nThree additional contracts on top of dry-run: (1) Idempotency-Key REQUIRED — a missing key returns 400 IDEMPOTENCY_KEY_REQUIRED. (2) X-Approval-Token REQUIRED — a single-use token minted via auth.approval_token, atomically consumed via the migration 033 RPC; rejected tokens map to APPROVAL_TOKEN_INVALID/USED/EXPIRED/MISMATCH. (3) Preconditions MUST pass — the same five dry-run checks run as a precondition gate; failures return 422 with the failed check list and do NOT consume the approval token (the agent can fix inputs and retry). Success returns 200 with a HMAC-SHA256-signed receipt envelope (mock or live mode). Audit chain: successful submission → `submit_mva` row; authorisation failure → `execute_authorization_failed`; post-consume submission failure → `submit_mva_failed`.","description_nb":"To ulike oppførsler på samme endepunkt, valgt med spørringsparameteren `?dry_run=true`.\n\nPRØVEINNSENDING (`?dry_run=true`): valider en innleveringshandling (mva_melding ELLER a_melding, begge støttes ved prøveinnsending) mot fem forhåndssjekker UTEN å sende noe til Altinn / Skatteetaten / NAV. Returnerer 200 med et strukturert DryRunOutcome som viser om hver sjekk er bestått eller feilet. Forbeholdsteksten minner om at en bestått prøveinnsending IKKE garanterer at den faktiske innleveringen lykkes.\n\nUTFØRELSE I PRODUKSJON (?dry_run utelatt eller noe annet enn 'true'): når produksjonsgodkjenningen i Maskinporten er aktivert, send innleveringen til Altinn 3 (videre til Skatteetaten / NAV). INNTIL DEN PORTEN ER ÅPNET er endepunktets kontrakt levert, men innsenderen er simulert (ALTINN_MODE=mock, som er standard; bryteren per integrasjon etter CLAUDE.md Rule 12, atskilt fra MASKINPORTEN_MODE som styrer autentiseringslaget mot Maskinporten): ruten kjører fra ende til ende gjennom kvitteringssignering + persistens + sporingslogg, men oppstrøms `altinn_receipt_id` er den deterministiske SHA-256-utledede MOCK-ALT-*-verdien fra den simulerte innsenderen. Utrulling i produksjon krever produksjonslegitimasjon for Maskinporten + godkjenning fra Skatteetaten som tjenesteeier for MVA-meldingen + en innsender for produksjon i src/lib/altinn/live-submitter.ts + godkjenning i DECISIONS.md (se DECISIONS.md PR-077 §1 for full aktiveringssjekkliste). v1 støtter kun mva_melding på produksjonsstien; innsending av a_melding i produksjon er sperret bak NAV-integrasjonen i produksjon og returnerer 403 PLAN_INSUFFICIENT i produksjonsmodus (prøveinnsending av a_melding støttes, kun innsending i produksjon er blokkert).\n\nTre ekstra kontrakter utover prøveinnsending: (1) Idempotency-Key PÅKREVD: manglende nøkkel returnerer 400 IDEMPOTENCY_KEY_REQUIRED. (2) X-Approval-Token PÅKREVD: engangstoken generert via auth.approval_token, atomisk forbrukt via migrasjon 033 RPC; avviste token gir APPROVAL_TOKEN_INVALID/USED/EXPIRED/MISMATCH. (3) Forhåndssjekkene MÅ bestås: de samme fem sjekkene fra prøveinnsendingen kjøres som forhåndskrav; feil returnerer 422 med listen over feilede sjekker og forbruker IKKE tokenet (agenten kan rette opp og prøve igjen). Suksess returnerer 200 med HMAC-SHA256-signert kvitteringspakke (simulert modus eller produksjonsmodus). Sporingskjede: vellykket → `submit_mva`-rad; autorisasjonsfeil → `execute_authorization_failed`; innsendingsfeil etter at tokenet er forbrukt → `submit_mva_failed`.","endpoint":{"method":"POST","path":"/api/v1/actions/execute"},"auth":"api_key","tier_minimum":"free","category":"actions","openapi_operation_id":"dryRunExecuteAction","example_request":"Dry-run: POST /api/v1/actions/execute?dry_run=true with headers { Authorization: Bearer <KEY> } and body { org_number, action_type, period, payload }. Live-execute: POST /api/v1/actions/execute with headers { Authorization: Bearer <KEY>, Idempotency-Key: <UUID>, X-Approval-Token: <token> } and body { org_number, action_type: \"mva_melding\", period, payload }. Both modes require API-key auth via Authorization header (round 5 manifest fix — was previously omitted from the dry-run half).","data_sources":["brreg","internal-rulebook","delegations","altinn","internal-supabase"],"freshness":"live","status":"dry-run"},{"id":"health.agent-readiness","name_en":"Agent-readiness probe","name_nb":"Beredskapssjekk for agenter","description_en":"Use this before submitting a batch of compliance workflows to verify Apier is healthy: returns the live task success rate and p95 latency per workflow class plus the live Maskinporten circuit-breaker state. Rates fail open to conservative static defaults until live telemetry accumulates; the `source` field tells you which you got.","description_nb":"Bruk denne før du sender en serie regulatoriske arbeidsflyter for å bekrefte at Apier er friskt: returnerer suksessrate og p95-latens i sanntid per arbeidsflytklasse, pluss gjeldende tilstand for strømbryteren mot Maskinporten. Ratene faller tilbake til konservative statiske standarder til telemetri fra drift har samlet seg; feltet `source` viser hvilken du fikk.","endpoint":{"method":"GET","path":"/api/v1/health/agent-readiness"},"auth":"none","tier_minimum":null,"category":"discovery","openapi_operation_id":"getAgentReadiness","example_request":"GET /api/v1/health/agent-readiness","data_sources":["internal-telemetry"],"freshness":"live","status":"live"},{"id":"public.pricing","name_en":"Machine-readable price list for metered endpoints","name_nb":"Maskinlesbar prisliste for målte endepunkter","description_en":"Use this FIRST, before any paid call, to discover what every metered endpoint and MCP tool costs. Zero auth — no API key needed. Returns each metered endpoint's cost in whole øre (100 øre = NOK 1), the matching MCP tool name, the top-up bounds and top_up_url, the low-balance-warning rule, and the exact machine-readable recovery contract a 402 INSUFFICIENT_CREDITS response carries (retryable, fix_hint, docs_url, top_up_url, balance_ore, cost_ore). Sourced from the SAME pricing configuration the 402 meter enforces — no parallel price table exists, but a previously fetched price can become stale after a pricing change, so the per-call metered response remains the authoritative charging signal. Prices only — balances live behind the authenticated /api/v1/account/credits/balance endpoint. Callable over the MCP server (/api/mcp) as the keyless tool `get_pricing` (PR-PAY-3).","description_nb":"Bruk denne FØRST, før noe betalt kall, for å finne ut hva hvert målte endepunkt og MCP-verktøy koster. Ingen autentisering: ingen API-nøkkel kreves. Returnerer hvert målte endepunkts kostnad i hele øre (100 øre = 1 kr), tilhørende MCP-verktøynavn, påfyllingsgrensene og top_up_url, regelen for varsel ved lav saldo, og den maskinlesbare gjenopprettingskontrakten et 402 INSUFFICIENT_CREDITS-svar bærer (retryable, fix_hint, docs_url, top_up_url, balance_ore, cost_ore). Hentet fra SAMME priskonfigurasjon som 402-måleren håndhever. Det finnes ingen parallell pristabell, men en tidligere hentet pris kan bli utdatert etter en prisendring, så det målte svaret per kall forblir det autoritative belastningssignalet. Kun priser: saldoer ligger bak det autentiserte endepunktet /api/v1/account/credits/balance. Kan kalles over MCP-serveren (/api/mcp) som det nøkkelfrie verktøyet `get_pricing` (PR-PAY-3).","endpoint":{"method":"GET","path":"/api/v1/pricing"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"getPricing","example_request":"GET /api/v1/pricing","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"public.errors","name_en":"Machine-readable error registry — every error_code with retry and fix guidance","name_nb":"Maskinlesbart feilregister: hver error_code med råd om nytt forsøk og utbedring","description_en":"Use this ONCE at startup to load a complete recovery policy before your first error. Zero auth — no API key needed. Returns every error_code any Apier surface can serialise (REST envelopes, the MCP tool-envelope taxonomy, the JSON-RPC transport, the dashboard billing routes, the operator surfaces), each with `retryable` (is an identical retry after a short backoff worth attempting?), `fix_hint_en` / `fix_hint_nb` (one-line imperative remediation in English and bokmål), `docs_url` (the code's anchor on /docs/errors) and `category` (closed set: auth, scope, validation, not_found, rate_limit, upstream, internal, billing). Sourced from the SAME error catalog the live envelope builder stamps those fields from — no parallel table exists, so a value looked up here always equals the value a real 4xx/5xx body carries; openapi.json publishes the identical set as the closed `ErrorCode` enum. Sorted by code, deterministic per deploy, strong ETag + If-None-Match → 304. Complements POST /api/v1/explain, which expands the explainer-backed subset into a full bilingual `explanation` object.","description_nb":"Bruk denne ÉN gang ved oppstart for å laste en komplett gjenopprettingspolicy før den første feilen. Ingen autentisering: ingen API-nøkkel kreves. Returnerer hver error_code noen Apier-flate kan sende (REST-konvolutter, MCP-verktøyenes feiltaksonomi, JSON-RPC-transporten, faktureringsrutene i dashbordet, operatørflatene), hver med `retryable` (er et identisk nytt forsøk etter en kort pause verdt å prøve?), `fix_hint_en` / `fix_hint_nb` (én linje med utbedringsråd på engelsk og bokmål), `docs_url` (kodens anker på /docs/errors) og `category` (lukket sett: auth, scope, validation, not_found, rate_limit, upstream, internal, billing). Hentet fra SAMME feilkatalog som konvoluttbyggeren stempler feltene fra. Det finnes ingen parallell tabell, så en verdi du slår opp her er alltid lik verdien en ekte 4xx/5xx-kropp bærer; openapi.json publiserer det identiske settet som den lukkede `ErrorCode`-enumen. Sortert etter kode, deterministisk per utrulling, sterk ETag + If-None-Match → 304. Utfyller POST /api/v1/explain, som utvider delmengden med forklaringsmal til et fullt tospråklig `explanation`-objekt.","endpoint":{"method":"GET","path":"/api/v1/errors"},"auth":"none","tier_minimum":null,"category":"public-tool","openapi_operation_id":"listErrorRegistry","example_request":"GET /api/v1/errors","data_sources":["internal-static"],"freshness":"static","status":"live"},{"id":"account.credit_balance","name_en":"Prepaid-credit balance for the calling API key","name_nb":"Forhåndsbetalt kredittsaldo for API-nøkkelen","description_en":"Use this to check the prepaid-credit balance of the API key you are calling with — the same per-key balance metered Category-B reads debit and the 402 INSUFFICIENT_CREDITS error reports. Returns `balance_ore` (whole øre; 5000 = NOK 50.00), `currency` (always NOK), `updated_at` (null when the key has never been topped up — the balance is then authoritatively 0), and `top_up_url` (byte-identical to the URL in the 402 body; a human tops up there). Takes no parameters: the only balance it can return is your own key's, so cross-key reads are structurally impossible. Read-only — checking your balance never debits anything. Callable over the MCP server (/api/mcp) as the tool `get_credit_balance` (PR-PAY-3).","description_nb":"Bruk denne for å sjekke den forhåndsbetalte kredittsaldoen til API-nøkkelen du kaller med: samme saldo per nøkkel som målte oppslag i Kategori B belaster, og som 402 INSUFFICIENT_CREDITS-feilen rapporterer. Returnerer `balance_ore` (hele øre; 5000 = 50,00 kr), `currency` (alltid NOK), `updated_at` (null når nøkkelen aldri er fylt på, og saldoen er da autoritativt 0) og `top_up_url` (identisk med URL-en i 402-svaret; et menneske fyller på der). Tar ingen parametre: den eneste saldoen som kan returneres er din egen nøkkels, så oppslag på tvers av nøkler er strukturelt umulig. Kun lesing: å sjekke saldoen belaster aldri noe. Kan kalles over MCP-serveren (/api/mcp) som verktøyet `get_credit_balance` (PR-PAY-3).","endpoint":{"method":"GET","path":"/api/v1/account/credits/balance"},"auth":"api_key","tier_minimum":"free","category":"account","openapi_operation_id":"getAccountCreditBalance","example_request":"curl -H 'Authorization: Bearer <API_KEY>' https://www.apier.no/api/v1/account/credits/balance","data_sources":["internal-supabase"],"freshness":"live","status":"live"},{"id":"account.topup_request","name_en":"Request a prepaid-credit top-up (human approval required)","name_nb":"Be om påfyll av forhåndsbetalt kreditt (krever menneskelig godkjenning)","description_en":"Use this when a metered call returned 402 INSUFFICIENT_CREDITS and you want funding without leaving the API: request a top-up of a specific whole-øre amount for the API key you are calling with. This creates a PENDING request only — nothing is charged, no checkout exists yet, and this surface never touches Stripe. A HUMAN reviews the request on the billing dashboard (the returned `approval_url`), and only their approval starts the existing card checkout, which they complete on Stripe's hosted page. Bounds: at least 1000 øre (NOK 10), at most the adjustable server-side ceiling (100000 øre = 1000 NOK at launch; an over-ceiling request returns 400 TOPUP_CEILING_EXCEEDED naming `requested_ore` and `ceiling_ore`, with two remedies — lower the amount, or hand over to a human who can top up without any ceiling). Requests expire after 24 hours; max 3 pending per account; 5 requests/hour per key. Any valid non-revoked key may call this — no scope required. The 402 body's `topup_request` field carries this endpoint's coordinates for zero-prose discovery.","description_nb":"Bruk denne når et målt kall returnerte 402 INSUFFICIENT_CREDITS og du vil skaffe midler uten å forlate API-et: be om et påfyll på et bestemt beløp i hele øre for API-nøkkelen du kaller med. Dette oppretter kun en VENTENDE forespørsel: ingenting belastes, ingen betaling finnes ennå, og denne flaten berører aldri Stripe. Et MENNESKE vurderer forespørselen på faktureringssiden (den returnerte `approval_url`), og først deres godkjenning starter den eksisterende kortbetalingen, som de fullfører på Stripes egen side. Grenser: minst 1000 øre (10 kr), maksimalt den justerbare servergrensen (100000 øre = 1000 kr ved lansering; en forespørsel over grensen gir 400 TOPUP_CEILING_EXCEEDED med `requested_ore` og `ceiling_ore`, og to løsninger: senk beløpet, eller la et menneske fylle på uten grense). Forespørsler utløper etter 24 timer; maks 3 ventende per konto; 5 forespørsler/time per nøkkel. Alle gyldige nøkler som ikke er tilbakekalt, kan kalle denne. Intet scope kreves. 402-svarets `topup_request`-felt bærer endepunktets koordinater for oppdagelse uten prosa.","endpoint":{"method":"POST","path":"/api/v1/billing/topup-requests"},"auth":"api_key","tier_minimum":"free","category":"account","openapi_operation_id":"createAgentTopupRequest","example_request":"curl -X POST -H 'Authorization: Bearer <API_KEY>' -H 'Content-Type: application/json' -d '{\"amount_ore\": 10000}' https://www.apier.no/api/v1/billing/topup-requests","data_sources":["internal-supabase"],"freshness":"live","status":"live"}],"available_scopes":["read:brreg","read:altinn","read:digdir","read:norgesbank","read:changes","read:audit","read:actions","read:rulebook","subscribe:webhooks","admin:keys"],"actions":{"dry_run_supported":true,"execute_supported":false,"action_types":["mva_melding","a_melding"]},"sandbox":{"available":true,"base_url":"https://www.apier.no/api/v1/sandbox","fixtures_url":"https://www.apier.no/api/v1/sandbox/fixtures","reserved_test_org_numbers":["999000001","999000002","999000003","999000004","999000005"],"magic_state_org_numbers":["999660010","999660029","999660037","999660045","999660053","999660061","999660088","999660096","999660118","999660126","999660134"],"reserved_error_org_numbers":{"999000901":"AUTH_MISSING_DELEGATION","999000902":"AUTH_EXPIRED_TOKEN","999000903":"VALIDATION_FAILED","999000904":"SCOPE_MISSING"},"simulate_error_param":"?simulate_error=<missing_delegation|invalid_token|validation_error|scope_missing|altinn_timeout|invalid_certificate|malformed_payload|upstream_5xx>","supported_error_codes":["missing_delegation","invalid_token","validation_error","scope_missing","altinn_timeout","invalid_certificate","malformed_payload","upstream_5xx"],"query_knobs":{"simulate_latency":{"unit":"ms","min":0,"max":30000},"mock_date":{"format":"YYYY-MM-DD","timezone":"Europe/Oslo"}},"magic_vat_values":[{"field":"total_revenue_nok","value":0,"outcome":"VALIDATION_FAILED","http_status":400},{"field":"total_revenue_nok","value":99999999,"outcome":"GOVERNMENT_VALIDATION_REJECTED","http_status":422},{"field":"period","value":"<YYYY-MM before mock_date/now>","outcome":"accepted (filed_late: true)","http_status":200}],"cors":"open","determinism":"byte-equivalent except _meta.response_timestamp"},"mcp":{"available":true,"server_url":"https://www.apier.no/api/mcp","schema_version":"2026.8.1","protocol":"json-rpc-2.0","tools_count_initial":3,"tools_count_active":26,"tools_count_planned":26,"deferred_tool_prs":[],"oauth":{"protected_resource_metadata":"/.well-known/oauth-protected-resource/api/mcp","authorization_servers":["https://ietncbksyajattlahlzs.supabase.co/auth/v1"]}},"multi_agent_safety":{"write_conflict_detection":true,"conflict_lock_ttls":{"mva_filing":600,"amelding_filing":300,"skattemelding_filing":1200,"aarsregnskap_filing":1800,"maskinporten_delegate":60}},"discovery":{"openapi":"/openapi.json","llms_txt":"/llms.txt","llms_full_txt":"/llms-full.txt","mcp_manifest":"/.well-known/mcp.json","agent_card":"/.well-known/agent-card.json","ai_plugin_manifest":"/.well-known/ai-plugin.json","security_txt":"/.well-known/security.txt","data_sovereignty":"/.well-known/data-sovereignty","workflows":"/workflows.json","mcp_endpoint":"/api/mcp"}},"_meta":{"rulebook_version":"1.0.0","data_freshness":"2026-08-21T00:00:00.000Z","last_verified":"2026-10-07T21:45:20.229Z","source":"apier.no internal manifest","schema_version":"1.1.0","response_timestamp":"2026-10-07T21:45:20.229Z","served_from":"static","active_optimize_mode":"cost","response_hash":"sha256:86555f590312d65e31d89a6b50fdee15ed1b40dda44f38789428bdaddc79e1c4"}}