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, paste it, done. 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's one call, no auth, 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.

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.

Authenticate any of the eight non-public sandbox routes with a synthetic bearer — no key, 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> during the beta, when every tier is free). 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.

Authentication — the full auth model, key issuance, and tier limits.
Endpoint reference — every operation, backed by /openapi.json.
Recipes — golden-path agent workflows with full request/response examples.

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

Quick start