---
title: "Machine-readable price list for every metered endpoint and MCP tool"
method: GET
path: "/api/v1/pricing"
tags: ["Discovery"]
---

# Machine-readable price list for every metered endpoint and MCP tool

`GET /api/v1/pricing`

## Request

- Base URL: `https://www.apier.no`
- URL: `https://www.apier.no/api/v1/pricing`
- Auth: none required

Public, zero-auth price discovery — call this FIRST, before any paid call, to learn what every metered endpoint and MCP tool costs. Derived from the SAME pricing configuration the 402 INSUFFICIENT_CREDITS meter enforces, so there is deliberately no second price table anywhere in the system; a previously fetched price can still become stale after a pricing change, and the per-call metered response remains the authoritative charging signal. Returns each metered endpoint's canonical path, HTTP method, pricing category and cost in whole øre (100 øre = NOK 1), the matching MCP tool name where one exists, the credit-unit convention, whether enforcement is currently live (while dark, metered calls are not charged and responses carry X-Credit-Check: shadow), the exact machine-readable recovery contract a 402 carries (top_up_url / balance_ore / cost_ore plus the catalog-derived retryable / fix_hint / docs_url), the balance-visibility surfaces (X-Credits-* response headers on REST, metadata.credits on MCP, and the authenticated /account/credits/balance self-read), the low-balance warning rule, and the top-up bounds with the billing-dashboard top_up_url. Prices ONLY — never balances, customer data, or any authenticated state; the endpoint is keyless by design so an agent can price a workflow before holding a key. Served fresh on every request: Cache-Control no-store (the body embeds the runtime enforcement.live mode, which must never be served stale from a shared cache) with a strong SHA-256 ETag honouring If-None-Match (304) — revalidation is answered at origin over the current body, so a 304 can never confirm a stale enforcement mode. The per-call metered response (X-Credit-Check / X-Credits-* headers, or a 402 body) is the authoritative charging signal; enforcement.authority_note states this in-band.

## Response `200`

The current price list. Deterministic for a given pricing configuration: same config, same price data — data_freshness/last_verified are PINNED to the pricing configuration's change stamp, and the ETag is computed over that stable representation (per-call wire markers like response_timestamp/response_hash are excluded from the ETag hash domain — the convention every cached read endpoint shares).

- object
  - `success` true, required
  - `data` object, required
    - `schema_version` string, required: Version of THIS response's shape (versioned machine interface, append-only fields).
    - `currency` 'NOK', required: All prices are Norwegian kroner, expressed in whole øre.
    - `credit_unit` string, required: Human/agent-readable statement of the whole-øre integer convention.
    - `metered_endpoints` object[], required: Every credit-metered endpoint, sorted by canonical path. An endpoint absent here is not metered.
      - `endpoint` string, required: Canonical OpenAPI endpoint form — the same string the debit ledger and provenance_log key on.
      - `method` 'GET' | 'POST', required
      - `category` string, required: Pricing category the endpoint inherits its cost from (one category, one cost).
      - `cost_ore` integer, required: Cost per call in whole øre.
      - `mcp_tool` string: The MCP tool wrapping this endpoint, when one exists. MCP tools inherit metering through the REST forward — same debit point, same price.
    - `unmetered_note` string
    - `enforcement` object, required
      - `live` boolean, required: false while credit enforcement runs dark (no debits, no 402 — responses carry X-Credit-Check: shadow); true once CREDITS_LIVE is flipped. Served no-store so the reported state can never be cache-stale — but it remains best-effort discovery: key charging decisions on the per-call metered response, not on a previously fetched price list (see authority_note).
      - `authority_note` string, required: Machine-readable authority caveat, stated in-band so an agent needs no out-of-band documentation: this endpoint is best-effort discovery — the authoritative charging signal is always the per-call metered response (X-Credit-Check: shadow = not charged; X-Credits-* headers or a 402 INSUFFICIENT_CREDITS body = enforcement live).
      - `insufficient_balance_status` 402, required
      - `insufficient_balance_error_code` 'INSUFFICIENT_CREDITS', required
      - `recovery_contract_fields` string[], required: The machine-readable top-level fields a 402 body carries for self-recovery.
    - `balance_visibility` object, required
      - `rest_headers` string[], required: The exact REST response-header names that carry balance visibility on successful metered calls while enforcement is live: X-Credits-Balance-Ore (remaining post-debit balance, whole øre), X-Credits-Cost-Ore (this call's price, whole øre), and — only strictly below the warning threshold — X-Credits-Warning (literal `low_balance`), X-Credits-Warning-Threshold-Ore, and X-Credits-Topup-Url. Headers, not the JSON body, so the envelope's provenance response_hash stays re-verifiable.
      - `mcp_metadata_field` string, required: Dot-path of the field on an MCP tool-result envelope that mirrors the REST balance headers on successful metered tool calls: `metadata.credits` carrying { balance_ore, cost_ore, balance_warning? }.
      - `balance_endpoint` string, required: Canonical path of the authenticated Bearer self-read that returns the calling API key's OWN prepaid balance at any time (read-only, never debits, deliberately scope-exempt).
    - `low_balance_warning` object, required
      - `factor` integer, required: The dimensionless multiplier in the warning threshold: a warning fires when the post-debit balance is STRICTLY below `factor × the call's cost_ore`. A balance of exactly factor × cost still covers `factor` more calls and does NOT warn.
      - `rule` string, required: Human/agent-readable statement of the threshold rule above, kept in the payload so an agent needs no out-of-band documentation to interpret the factor.
    - `top_up` object, required
      - `min_ore` integer, required: Smallest accepted top-up per transaction on the DASHBOARD CHECKOUT path, in whole øre (5000 = NOK 50 — below Stripe's per-transaction fee floor a top-up is economically nonsensical). NOT the floor on the agent top-up-request path, which is lower — see `bounds_scope` and `paths`.
      - `max_ore` integer, required: Largest accepted top-up per transaction on the DASHBOARD CHECKOUT path, in whole øre (1000000 = NOK 10,000 — bounds card-fraud blast radius on a prepaid surface). The agent top-up-request path has a separate, operator-adjustable ceiling — see `paths.agent_request`.
      - `top_up_url` string, uri, required: Absolute URL of the billing dashboard where a HUMAN completes the top-up — byte-identical to the top_up_url in the 402 INSUFFICIENT_CREDITS body and on the balance endpoint (one server-side builder, so agents may hard-code the handover from any of the three surfaces).
      - `bounds_scope` 'dashboard_checkout': Which funding path the sibling `min_ore` / `max_ore` / `top_up_url` fields describe. Always `dashboard_checkout`: those three fields predate the two-path split and are retained unchanged (append-only), so this field states in-band which path they govern rather than leaving an agent to assume they cover its own top-up REQUEST — whose floor is lower and whose ceiling is a live operator setting.
      - `paths` object: Per-path funding bounds. There are TWO ways credits reach a balance and they carry DIFFERENT bounds; validate an amount against the path you are actually using.
        - `dashboard_checkout` object: A HUMAN completes a card payment on the billing dashboard. Bounds are code constants validated by the checkout session.
          - `description` string
          - `min_ore` integer
          - `max_ore` integer
          - `top_up_url` string, uri
        - `agent_request` object: An AGENT requests funding without leaving the API; a human then approves and pays. The agent surface never touches a card.
          - `description` string
          - `endpoint` string: Canonical OpenAPI path of the agent-initiated request route.
          - `method` 'POST'
          - `amount_field` string: Name of the request-body field carrying the whole-øre amount.
          - `min_ore` integer: Floor for an agent-initiated request, in whole øre (5000 = NOK 50). The SAME floor as the dashboard checkout, single-sourced from it: the human approval leg re-validates against the checkout bounds, so a request below the floor can never be approved.
          - `max_ore` integer, nullable: Always `null` on this endpoint, by design — NOT an omission and NOT unlimited. The ceiling lives in the service-role-only `billing_settings` table and an operator can change it at any time; this endpoint is keyless and its ETag is computed over static configuration, so reading live DB state here would either break determinism or advertise a stale ceiling. Read the live value from `topup_request.ceiling_ore` on the 402 INSUFFICIENT_CREDITS body.
          - `max_ore_source` string: Where the live ceiling is stored, named so an operator and an agent are describing the same setting (`billing_settings.agent_topup_ceiling_ore`).
          - `max_ore_note` string: In-band statement of the ceiling's mutability and where the live value is carried.
    - `subscription_tiers` object: Pointer to the OTHER billing mechanism. This endpoint prices METERED per-call company-data reads; a subscription tier is independent of them — it buys enforced rate-limit ceilings (per-minute Category A, the stricter per-minute Category B, and a per-organisation daily cap) plus a support level. A subscription includes NO bundle of metered reads and there is no per-call overage; a credit balance raises NO rate limit. The symmetric counterpart of this pointer is the `credits` object on /pricing.json.
      - `pricing_json_url` string, uri: Machine-readable subscription-tier list (schema_version, status/billing_live, annualDiscountPct, per-tier limits + features, combos).
      - `pricing_page_url` string, uri: Human-readable pricing page.
      - `note` string: In-band statement that the two mechanisms are independent, so an agent needs no out-of-band documentation to avoid modelling a subscription as a call allowance.
    - `how_to_pay_guide` string, uri: The agent-facing walkthrough of the full payment loop (discover → 402 → top up → retry).
  - `_meta` TrustMetadata, required: Metadata included in every response for trust and verifiability.
    - `rulebook_version` string, required: Current Rulebook version. Internal rule-version records carry structured origin metadata (`initial_seed` | `human_review` | `lovdata_drift_response` | `audit_finding` | `customer_question` | `legal_correction`) for operator forensics, but that attribution is deliberately NOT exposed on public responses to avoid leaking operational signal.
    - `data_freshness` string, date-time, required: When this data was last fetched (ISO 8601 UTC).
    - `last_verified` string, date-time, required: When this data was last verified against source (ISO 8601 UTC).
    - `source` string, required: Origin of this data. Defaults to `apier.no`. The agent-readiness probe (`GET /api/v1/health/agent-readiness`) is the one surface that may instead emit `apier.no telemetry` — it does so when at least one of its endpoint rates came from measured live telemetry, and falls back to `apier.no` when every rate is a static default; all other endpoints always emit `apier.no`.
    - `data_source` string: Authoritative origin of the underlying data (listed alongside rulebook_version, data_freshness, last_verified, legal_basis for Rulebook-influenced endpoints). Distinct from `source` (the response origin): `data_source` identifies the authoritative data publisher — e.g. 'Brønnøysund Enhetsregisteret + Apier Universal Rulebook'. Present on registry-backed endpoints.
    - `served_from` 'cache' | 'live' | 'static': Cache-aware endpoints only — 'cache' when the response was served from the local copy, 'live' when the gateway just refreshed from the upstream, 'static' when the payload was computed deterministically from pure code with no DB or upstream read (e.g. /v1/public/deadlines). Absent on endpoints that don't carry this semantic.
    - `stale` boolean: Cache-aware endpoints only — true when the upstream was unreachable and a within-limit cached row was served as a fallback. Absent on normal responses.
    - `schema_version` string, required: OpenAPI contract version at the time of the response; matches `info.version`. Always present on every `/v1/*` response so a future schema break can be traced to the exact rows / audit events that predate / postdate it. Agent-facing machine interfaces (v1/capabilities, workflows.json) may override with their own narrower surface version; all other endpoints inherit the manifest-level version.
    - `legal_basis` string: Legal basis under which the response data is reused. Present on Rulebook-influenced endpoints (v1/company/{org}/obligations, /v1/company/{org}/deadlines). Common value: 'NLOD — public registry reuse'.
    - `rule_count` integer: Rule-evaluation count — total rules evaluated for this request. Present on endpoints that invoke the Rulebook evaluator (v1/company/{org}/obligations).
    - `applicable_count` integer: Count of rules whose evaluation_result is 'applicable'. Present on evaluator endpoints.
    - `not_applicable_count` integer: Count of rules whose evaluation_result is 'not_applicable'. Present on evaluator endpoints.
    - `insufficient_data_count` integer: Count of rules whose evaluation_result is 'insufficient_data' (Tier 2 gated). Present on evaluator endpoints. rule_count = applicable_count + not_applicable_count + insufficient_data_count.
    - `cache_age_ms` integer, nullable: Cache layer: milliseconds since the cached row was computed, or null on a cache miss (served_from === 'live'). Agents use it alongside data_freshness as a staleness signal. Present on endpoints wired to the cache (v1/company/{org}/obligations, /deadlines, /summary, /v1/public/obligations, /v1/public/deadlines).
    - `response_time_ms` integer: Speed signal: total server-side processing time in milliseconds, measured via performance.now() at the route boundary. Mirrored on the `X-Apier-Response-Time-Ms` header so agents can key on it without parsing the body. Present on every endpoint.
    - `response_timestamp` string, date-time: RFC 3339 / ISO 8601 UTC timestamp stamped by the response builder at wire-exit. Mirrored on the `provenance_log.response_timestamp` column by a fire-and-forget writer. Distinct from `data_freshness` (when upstream data was fetched) and `last_verified` (when the citation was verified); this is the moment the envelope left the server. Always populated at runtime — deliberately left out of the `required` list to avoid a cascading contract change that would invalidate every pre-existing example envelope in this spec (append-only response contracts). A future revision may promote it into the `required` list alongside a bulk example refresh.
    - `response_hash` string: SHA-256 hash of the canonical-JSON form of the envelope with `_meta` stripped before hashing, prefixed with `sha256:`. Mirrored on `provenance_log.response_hash` so a consumer can independently re-hash the bytes they received and compare against what we persisted (integrity receipt). Stripping `_meta` is load-bearing: volatile fields (response_time_ms, cache_age_ms, served_from) and the hash itself would otherwise feed into the digest and break the cache-hit-bytewise-identical invariant.
    - `source_snapshot_id` string: Optional free-text pointer into an upstream sync snapshot the response derives from — e.g. a Brreg sync's `brreg-<ISO>` snapshot id. Absent when the response is not tied to a specific upstream snapshot (capabilities, tools, static deadlines).
    - `is_sandbox` true: Present and `true` only when the response was generated from sandbox fixture data (currently `ALTINN_MODE=sandbox` on `/api/v1/altinn/list-acting-capacity`). Absent (NOT `false`) on every other response — the absent-vs-false distinction is deliberate so downstream agents branching on `if (response._meta.is_sandbox)` cannot be misled into treating non-sandbox responses as positively-confirmed-not-sandbox. Distinct from the `/v1/sandbox/*` `is_sandbox: true` literal in `SandboxMeta` (which carries the sandbox surface tag); this flag rides through the production `/api/v1/altinn/*` surface to forensically tag a sandbox-mode response that an OEM evaluator received.
    - `cost_nok` number: What this call debited from the caller's prepaid credit balance, in NOK, rendered from the integer-øre ledger (50 øre → 0.5; the ledger itself never leaves whole øre and no float arithmetic touches a balance). Present on the 2xx body of every metered company-data read — the same debit that sets the `X-Credits-Cost-Ore` header, so the two never disagree. `0` when nothing was charged: credit enforcement running dark (the response then also carries `X-Credit-Check: shadow`) or the sandbox surface. Absent on unmetered endpoints and on error envelopes — a refunded 5xx/403/404 claims no cost rather than a wrong one. Lives under `_meta`, which `response_hash` excludes, so the provenance receipt is unaffected; the route's ETag is computed before the credit wrapper stamps it, so a conditional request can still short-circuit to 304. Append-only addition.
    - `wallet_remaining_nok` number, nullable: The prepaid credit balance remaining AFTER this call's debit, in NOK (same rendering as `cost_nok`; mirrors the `X-Credits-Balance-Ore` header). `null` when no balance was read: credit enforcement running dark, or the sandbox surface. Present wherever `cost_nok` is. An agent planning a sequence of metered calls can divide this by the per-call price from GET /api/v1/pricing to know how many reads remain before a 402 INSUFFICIENT_CREDITS. Append-only addition.
    - `spend_cap_remaining_nok` number: What the calling key may still spend under its tighter spend cap (Europe/Oslo calendar day or month) AFTER this call's debit, in NOK (same rendering as `cost_nok`; never below 0). Present on the 2xx body of a metered read only when credit enforcement is live AND the key has a daily or monthly cap (set with PATCH /api/v1/account/keys/{id}); absent otherwise. When it reaches 0 the next metered call on this key returns 402 SPEND_CAP_REACHED until the cap resets. Append-only addition.

## Other responses

- `304`: Not Modified — the client's If-None-Match matched the current ETag: the pricing configuration AND the enforcement mode are unchanged (both are inside the ETag's hash domain), so the client's held representation is still valid. Empty body per RFC 9110; the ETag is re-emitted and Cache-Control stays `no-store` — conditional requests are an application-layer revalidation surface here, always answered at origin, never a shared-cache one.
- `429`: Per-minute rate limit reached for this (IP, endpoint) bucket on a zero-auth public endpoint. The `Retry-After` header indicates how many seconds to wait before the window resets. Public endpoints share a single soft-cap of 1000 requests per minute PER IP — there is no tier scaling, because callers aren't authenticated. Every allowed response also carries the standard `X-RateLimit-*` headers. On rare infrastructure-side failures the gateway fails OPEN and passes the request through with `X-RateLimit-Check: skipped`.

---

[API](https://skmtc.dev/apier/apis/apier-no-api.md) · [All operations](https://skmtc.dev/apier/apis/apier-no-api/llms.txt) · [OpenAPI document](https://skmtc.dev/apier/apis/apier-no-api/revisions/9ec19bc87311?raw)