The fastest way for an AI agent to orient itself against a Norwegian organisation: one HTTP round-trip returns the company's entity_type + data tier, the full obligation catalogue the Universal Rulebook evaluates for that entity_type, and the concrete rolling deadline calendar — side-by-side with _meta trust metadata naming the upstream source and legal basis for reuse.

What this endpoint returns (and does NOT return)

The response is deliberately narrow: data.org_number, data.entity_type, data.data_tier, data.obligations, data.deadlines, data.upgrade_path, and _meta. It includes nace_codes but not the rest of the full /context surface — no name, status, municipality, signaturrett, prokura, or role holders. If you need those, call /api/v1/company/{org}/context alongside this endpoint; both are backed by the same BRREG cache so the extra call is cheap.

When to call this

Agents should make this endpoint their FIRST call when onboarding a new organisation — the fan-out saves two round-trips (obligations + /deadlines) and guarantees both views are computed from the same rule version and company snapshot, so downstream reasoning doesn't have to reconcile drifting data.

Response shape (composition, not new logic)

The response composes outputs of three already-published pipelines — call-site semantics are identical to the individual endpoints:

• data.obligations: every rule whose entity_types[] matches the company, one EvaluationResult each, with all three verdicts (applicable / not_applicable / insufficient_data) side-by-side so agents can see the full picture. Same shape and ordering (rule_id ASC) as /api/v1/company/{org}/obligations.
• data.deadlines: per-period expansion of applicable obligations inside a rolling from_date + horizon_months window. Entries are sorted due_at ASC (nulls last); the same input twice produces byte-identical output. Same shape as /api/v1/company/{org}/deadlines.
• data.upgrade_path: Norwegian call-to-action pointing at the Altinn delegation flow. Populated on tier_1 responses, null on tier_2. Wording is entity-agnostic — it doesn't name specific obligations because the set of Tier-2-gated rules varies by entity_type.
• _meta: same RulebookTrustMetadata shape as /obligations — rulebook_version, data_freshness, last_verified (MIN of legal_reference_verified_at across the rules actually evaluated — never newer than the weakest citation), legal_basis, data_source, schema_version, and the four evaluation counts. Present on BOTH success and error responses so data_source / legal_basis / schema_version are never stripped on the 4xx/5xx path.

Tier 1 vs Tier 2 semantics

When a Tier 2 Altinn delegation is active AND the Registry has populated Tier 2 fields for the org, data_tier flips to tier_2, upgrade_path is nulled, and every deadlines[].filing_status is resolved against the compliance_states surface: filed / overdue land verbatim from the compliance record; pending / in_progress / failed / missing rows collapse to unknown because the lookup doesn't see due_at and can't commit to upcoming vs overdue on its own (no silent fallbacks).

On tier_1 the filing-status lookup is not injected, so the deadline engine auto-derives upcoming / overdue from due_at vs from_date — the honest pre-delegation view.

Rulebook verification gate

Only rules whose citations have been human-verified against Lovdata (a required database migration — legal_reference_verified_at IS NOT NULL) reach this endpoint. Unverified rules stay in staging until a human confirms them, preserving the framing ("Verified against [source] version [X] as of [date]").

Rate limit

Category B quotas apply: Free 30/min, Starter 150/min, Professional 300/min, Enterprise unlimited — stricter than Category A because the response carries personal-adjacent company data. Progressive backoff kicks in at >100 unique org numbers per hour per key.

{
  "data": {
    "mva_registered": true,
    "obligations": [
      {
        "rule_id": "MVA_REGISTRATION_THRESHOLD",
        "obligation_name": "mva_registration",
        "legal_reference": "Merverdiavgiftsloven § 2-1",
        "deadline_rule": "mva_termin_10th_second_month"
      }
    ],
    "deadlines": [
      {
        "obligation_id": "AMELDING_MONTHLY",
        "period_label": "2026-01"
      }
    ]
  },
  "_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
  }
}