Resolve a Norwegian organisasjonsnummer to a structured company profile
Given a 9-digit Norwegian organisasjonsnummer, returns a structured company profile sourced from Brønnøysund Enhetsregisteret (data.brreg.no). The agent-facing response carries the company's display name, organisational form (e.g. AS — Aksjeselskap, ENK — Enkeltpersonforetak, ASA — Allmennaksjeselskap), Norwegian industry codes (NACE) with descriptions, the registered street address (forretningsadresse), any separate business address (postadresse), the Enhetsregisteret registration date, the agent-facing status enum (active for operating entities, dissolved for deleted/bankrupt/liquidating entities), the dissolution date when known (slettedato → dissolved_at), the MVA-registered flag (registrertIMvaregisteret), and a deduplicated list of role codes assigned to natural persons (DAGL, LEDE, MEDL, NESTL, INNH, etc.). The response carries role codes ONLY — never personal identifiers (fødselsdato, personnummer, home address, email, phone). Two-layer PII defense is enforced: the parser declares an explicit allowlist (LAYER 1) and runs a recursive deep-scan with fnr-shape regex (LAYER 2) before any value reaches the response, the cache row, the audit_log, the company_delta_log, or the changes archive. Cache TTL is 24 hours; if Brønnøysund is unavailable, the response may serve a stale cached row up to 7 days old with metadata.stale=true and metadata.staleness_seconds populated. Beyond the 7-day ceiling we 503 UPSTREAM_UNAVAILABLE (silently serving older data would mislead agents). The data is Tier 1 public infrastructure under NLOD (Norsk lisens for offentlige data); no delegation is required. Required scope: read:brreg. The MCP tool get_company_profile proxies through this endpoint via the registry pattern — REST and MCP callers share one source of truth. This is the one metered POST, so it honours the Idempotency-Key header: a retry carrying the same key and body is answered from the cached first response with Idempotent-Replay: true and is NOT debited a second time — the replay short-circuits before the credit check. Without the header every call is an independent metered read.
Request
- Base URL: https://www.apier.no
- URL: https://www.apier.no/api/v1/brreg/company-profile
- Auth: HTTP bearer
Headers
Optional client-chosen key that makes this write safely retriable. When the same key is presented on a subsequent request with the same body, the gateway returns the original response (with Idempotent-Replay: true) instead of re-executing the write. Reservation is scoped to (consumer, endpoint, key) so the same key on different endpoints or different consumers does not collide. TTL: 24 hours. The key must be 1–255 printable ASCII characters — a v4 UUID or ULID is the recommended format. Keys are SHA-256 hashed before storage so they may safely carry client-internal identifiers.
Request body
Response
Company profile resolved. The response wraps the agent envelope under data (the standard /api/v1/* { success, data, _meta } shape; the MCP executor exposes data as the top-level { result, justification, metadata } envelope to MCP callers).
Example response
{
"_meta": {
"rulebook_version": "v1.0.0",
"source": "apier.no",
"data_source": "Brønnøysund Enhetsregisteret + Apier Universal Rulebook",
"schema_version": "1.0.0",
"legal_basis": "NLOD — public registry reuse",
"response_timestamp": "2026-04-24T12:00:00.000Z",
"response_hash": "sha256:0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef",
"source_snapshot_id": "brreg-2026-04-24T02:00:00.000Z",
"cost_nok": 0.5,
"wallet_remaining_nok": 9.5,
"spend_cap_remaining_nok": 12.5
}
}Changes
No recorded changes to this operation across all 1 revision of this API.