Skip to content
Apier.no

Quick start

Your first Apier.no call in under five minutes, with no signup and no API key.

[Cite this as: Apier.no Docs v0.1.0 — last updated 2026-04-23]

This guide gets you from zero to three working API calls in under five minutes. Step 1 needs no signup and no API key: copy the cURL and paste it. Steps 2 and 3 stay on the zero-auth Category A surface so you can evaluate the contract before registering.

Step 1 — Your first call (no auth required)

These public endpoints need no API key. Copy the cURL below and run it in your terminal:

curl "https://www.apier.no/api/v1/public/obligations?entity_type=AS"

You'll get back a JSON payload listing every regulatory obligation that applies to a Norwegian AS (aksjeselskap): MVA registration, skattemelding, årsregnskap, A-melding, and the revisor thresholds, each one with its legal citation and a tier_2_required flag marking the ones that need a delegated system user before a concrete company-specific verdict can be computed:

{
  "success": true,
  "data": {
    "entity_type": "AS",
    "obligations": [
      {
        "obligation_id": "mva-registration",
        "obligation_name": "Registrering i Merverdiavgiftsregisteret",
        "category": "registration",
        "frequency": "one-time",
        "required": "conditionally",
        "condition": "Selskapet må registreres i Merverdiavgiftsregisteret når avgiftspliktig omsetning overstiger 50 000 kr i en 12-månedersperiode.",
        "tier_2_required": true,
        "legal_reference": "Merverdiavgiftsloven § 2-1",
        "source_url": "https://lovdata.no/lov/2009-06-19-58/§2-1"
      },
      {
        "obligation_id": "skattemelding-annual",
        "obligation_name": "Skattemelding for aksjeselskap",
        "category": "tax",
        "frequency": "annual",
        "required": "always",
        "condition": null,
        "tier_2_required": false,
        "legal_reference": "Skatteforvaltningsloven § 8-2",
        "source_url": "https://lovdata.no/lov/2016-05-27-14/§8-2"
      }
    ],
    "notes": []
  },
  "_meta": {
    "rulebook_version": "1.0.0",
    "data_freshness": "2026-04-22T10:05:07.813Z",
    "last_verified": "2026-04-21T10:05:07.813Z",
    "source": "apier.no",
    "data_source": "Brønnøysund Enhetsregisteret + Apier Universal Rulebook",
    "legal_basis": "NLOD — public registry reuse",
    "schema_version": "1.0.0"
  }
}

That one call needs no auth and returns real regulatory data.

Step 2 — Decode the _meta envelope

Every Rulebook-influenced response carries a _meta block. It's the trust signal agents build reasoning on:

  • rulebook_version: which Rulebook the verdict was computed under. A bump means the rules may have changed.
  • data_freshness: when this data was last fetched from the upstream registry (ISO 8601 UTC).
  • last_verified: the most recent manual verification timestamp, expressed as: "Verified against [source] version [X] as of [date]."
  • data_source: authoritative origin, e.g. Brønnøysund Enhetsregisteret. Distinct from source (the response origin: apier.no).

Agents can diff rulebook_version across two calls to detect whether a rule change happened between them, and can surface last_verified to end users as an auditable reference.

Step 3 — A second zero-auth endpoint

Try the calendar-year deadlines endpoint. Same zero-auth contract, same _meta envelope, weekend-and-holiday-adjusted Europe/Oslo dates. Omitting year defaults to the current Oslo calendar year:

curl "https://www.apier.no/api/v1/public/deadlines?year=2026"

The response lists every Norwegian obligation deadline for the requested calendar year (MVA terminer, A-melding, skattemelding, årsregnskap — January 1 through December 31 of year). Each entry carries an applies_to_entity_types array so an agent filtering for AS or ENK can pick the relevant rows in one pass.

Or pull a Norges Bank exchange rate, the third zero-auth endpoint:

curl "https://www.apier.no/api/v1/tools/exchange-rate?currency=EUR"

All three of these endpoints are Category A: no API key, no rate limit per consumer (soft IP-based cap only), and documented at /openapi.json with OpenAPI 3.1 examples fields you can copy verbatim.

Try the sandbox — full shapes, no signup

The three calls above are real but read-only. To rehearse the authenticated surface (per-company context, dry-run filings, the receipt and audit shapes) without registering, use the sandbox. It serves deterministic synthetic data, never calls a government system, and tags every response with _meta.is_sandbox: true.

The no-signup synthetic bearer

Authenticate any of the eight non-public sandbox routes with a synthetic bearer, with no key and no signup:

Authorization: Bearer apier_sandbox_test_<uuid>

The <uuid> suffix (1–64 characters of [A-Za-z0-9_-]) is your private session namespace. Generate a fresh one per agent or per run (a crypto.randomUUID() is ideal) and reuse it across the calls in that session. Two different suffixes never see each other's state, so parallel agents stay isolated. Treat the suffix as opaque; the sandbox hashes it before it reaches any log.

1. A zero-auth public read

The public sandbox mirror needs no bearer at all. Org 999999999 is the single org it serves:

curl "https://www.apier.no/api/v1/sandbox/public/company/999999999/summary"

You get the same envelope as the production /api/v1/company/{org}/summary, plus _meta.is_sandbox: true.

2. A keyed read against the richer fixtures

The eight non-public routes carry a richer fixture set — Tier 2 companies, full and partial delegation graphs, late and filed deadlines. Pick a reserved test org from the fixtures reference and pass the synthetic bearer:

curl -H "Authorization: Bearer apier_sandbox_test_<uuid>" \
  "https://www.apier.no/api/v1/sandbox/company/{org}/summary"

Substitute {org} with one of the reserved test orgs the fixtures reference lists, for example the Tier 2 company. The public org 999999999 is not served here; the two fixture pools are deliberately disjoint.

3. A dry-run that previews the submission

Before any filing, ?dry_run=true runs the five prerequisite checks and echoes back the exact body a live execute would send; nothing is submitted:

curl -X POST \
  -H "Authorization: Bearer apier_sandbox_test_<uuid>" \
  -H "Idempotency-Key: <unique-per-request>" \
  -H "Content-Type: application/json" \
  -d '{"org_number":"<reserved-test-org>","action":"mva_melding","payload":{"period":"2026-05","total_revenue_nok":"500000"}}' \
  "https://www.apier.no/api/v1/sandbox/actions/execute?dry_run=true"

The response carries data.would_be_payload (your payload, verbatim) and data.preview_notice: "preview only — not submitted". The magic payload values that force accepted / late / rejected outcomes on a live sandbox execute are documented in the fixtures reference.

4. Read the receipt and audit back

A live sandbox execute returns a signed mock receipt under data.receipt (altinn_receipt_id, audit_log_id, signature, and a _sandbox_marker so nothing can be mistaken for a real government response). You can also read the synthetic audit trail:

curl -H "Authorization: Bearer apier_sandbox_test_<uuid>" \
  "https://www.apier.no/api/v1/sandbox/company/{org}/audit"

The audit-as-inspection guide walks through using correlation_id and initiated_by to reconstruct what happened, the agent-side substitute for a dashboard.

Prefer a real key?

Sign up, open your dashboard, and create a key; it is shown in full exactly once and is prefixed apr_<tier>_ (for example apr_free_<your_key_here> on the free tier). A real key works on /api/v1/sandbox/* too, where it still returns mock data and submits nothing; use it on the production /api/v1/* endpoints when you are ready. The synthetic bearer is rejected on production routes; see Authentication for the full key model and the sandbox isolation contract, and Going live for the switch to real filings.

What's next

To go beyond the public surface (per-company obligations, filing status, action submission) you'll need an API key. Category B endpoints (/api/v1/company/{org}/*) require Authorization: Bearer <YOUR_API_KEY> and are per-key-rate-limited by tier.

If an endpoint returns an error, every 4xx/5xx carries a structured error_code + explanation; the full shape is covered in Error handling.

Building with an LLM? Read llms.txt for agent-oriented integration guidance.