Jobb-oppskrift · Selskapsverifisering

Onboard en kundevirksomhet (KYB) fra ett organisasjonsnummer

Jobben

Du onboarder en ny norsk kundevirksomhet og må svare på fire spørsmål før forholdet starter: finnes selskapet og er det aktivt, hvem kan tegne det, hva viser regnskapene, og hvilke plikter og frister gjelder — med en proveniens-stemplet dokumentasjonssti for hvert svar.

Endepunkter

GET /api/v1/company/{org}/verify
GET /api/v1/company/{org}/authority
GET /api/v1/company/{org}/accounts
GET /api/v1/company/{org}/obligations
GET /api/v1/company/{org}/deadlines

Forespørsel

curl -H 'Authorization: Bearer <API_KEY>' \
  'https://www.apier.no/api/v1/company/999999999/verify?certificate=true'

curl -H 'Authorization: Bearer <API_KEY>' \
  'https://www.apier.no/api/v1/company/999999999/authority?certificate=true'

curl -H 'Authorization: Bearer <API_KEY>' \
  https://www.apier.no/api/v1/company/999999999/accounts

curl -H 'Authorization: Bearer <API_KEY>' \
  https://www.apier.no/api/v1/company/999999999/obligations

curl -H 'Authorization: Bearer <API_KEY>' \
  https://www.apier.no/api/v1/company/999999999/deadlines

Svar (steg 1 — verifisering med sertifikat)

{
  "success": true,
  "data": {
    "result": {
      "org_number": "999999999",
      "name": "Synthetic Test AS",
      "entity_type": "AS",
      "verification_status": "pass",
      "signals": {
        "is_active": true,
        "not_bankrupt": true,
        "not_under_dissolution": true,
        "not_forcibly_dissolved": true,
        "has_signing_authority_defined": true,
        "has_filed_annual_accounts": true,
        "mva_registered": true
      },
      "summary": "Organisasjonen er registrert og aktiv, med definert signaturrett.",
      "signing_authority_summary": "Styreleder",
      "last_accounts_year": 2024,
      "municipality": "Oslo"
    },
    "issuer": "https://www.apier.no",
    "issued_at": "2026-07-07T09:00:00+02:00",
    "kid": "apier-2026-synthetic",
    "jwks_uri": "https://www.apier.no/.well-known/jwks.json",
    "rulebook_version": "1.0.0",
    "audit_log_ref": "sha256:7c9fa136d4413fa6173637e883b6998d32e1d675f88cddff9dcbcf331820f4b8",
    "signature": "eyJhbGciOiJSUzI1NiJ9..synthetic-detached-jws-signature-sample"
  },
  "_meta": {
    "rulebook_version": "1.0.0",
    "data_freshness": "2026-06-16T06:00:00.000Z",
    "last_verified": "2026-06-16T06:00:00.000Z",
    "source": "apier.no",
    "schema_version": "1.0.0",
    "data_source": "Brønnøysund Enhetsregisteret",
    "legal_basis": "NLOD — public registry reuse"
  }
}

Hvert av de fem svarene bærer _meta.response_hash og lander en rad i proveniensloggen — den samlede onboarding-vurderingen er altså dokumenterbar per delsvar. Vist over er steg 1 med ?certificate=true: verdiktet pakket i et frakoblet JWS-signert sertifikat du kan re-verifisere offline mot jwks_uri (steg 2 /authority støtter det samme flagget). Steg 3–5 returnerer regnskaps-, plikt- og fristformene fra sine egne oppskrifter. Sertifikatet er valgfritt — uten flagget får du det vanlige verdiktet med samme response_hash.

Neste steg

Stopp kjeden tidlig på verification_status «fail», og flagg «warn» (aktivt selskap uten definert signaturrett) for manuell vurdering i stedet for å blokkere hardt.
Hvis plikter returnerer insufficient_data på Tier 1, sett opp en Altinn-delegering (se Signatur + fullmakt-oppskriften for hvem som kan godkjenne den).
Lagre response_hash-verdiene (og eventuelle sertifikater) sammen med onboarding-beslutningen — det er dokumentasjonsstien din ved en senere kontroll.