Skip to content
Apier

Job recipe · Company Verification

Onboard a client company (KYB) from a single org number

The job

You are onboarding a new Norwegian client company and need four answers before the relationship starts: does the company exist and is it active, who can sign for it, what do its accounts show, and which obligations and deadlines apply — with a provenance-stamped paper trail for every answer.

Endpoints

  • 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

Request

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

Response (step 1 — verification with certificate)

{
  "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"
  }
}

Each of the five responses carries _meta.response_hash and lands a provenance-log row — so the assembled onboarding assessment is documentable per part-answer. Shown above is step 1 with ?certificate=true: the verdict wrapped in a detached-JWS-signed certificate you can re-verify offline against jwks_uri (step 2 /authority supports the same flag). Steps 3–5 return the accounts, obligations and deadlines shapes from their own recipes. The certificate is optional — without the flag you get the plain verdict with the same response_hash.

Next steps

  • Stop the chain early on a verification_status of “fail”, and flag “warn” (active company without defined signing authority) for manual review rather than hard-blocking.
  • If obligations return insufficient_data on Tier 1, set up an Altinn delegation (see the Signature + Authority recipe for who can approve it).
  • Store the response_hash values (and any certificates) alongside the onboarding decision — that is your paper trail for a later review.