Copy-paste API calls bucketed into the four workflows AI agents actually run against Norwegian regulatory infrastructure. Every request hits a merged endpoint documented at /openapi.json; every response matches the live shape. For the agent-first discovery manifest see /api/v1/capabilities.
Read
Fetch regulatory facts and company data. Two free zero-auth surfaces and one Tier-1+Tier-2 company read.
List universal obligations for an entity type
Fetch the canonical obligation template set for a Norwegian entity type. Zero-auth, no signup.
{
"success": true,
"data": {
"dimensions": [
{
"dimension": "authentication",
"apier": "Consumers authenticate with an API key over HTTPS; Maskinporten client registration, key management, and machine-to-machine token exchange against government endpoints are operated by Apier.",
"direct_integration": "The integrator registers their own Maskinporten client, manages an asymmetric key pair, and implements the signed-JWT token exchange for each government scope they need."
},
{
"dimension": "delegation_and_authority",
"apier": "Registered signature and prokura roles from the Brønnøysund registers and Altinn delegation state are exposed through normalised endpoints with a single response envelope.",
"direct_integration": "The integrator queries the Brønnøysund role registers and the Altinn delegation APIs separately and combines the results themselves."
},
{
"dimension": "audit_trail",
"apier": "API activity is recorded in an append-only audit log, and every response carries provenance metadata (response hash and wire timestamp) for later reconstruction.",
"direct_integration": "Consumer-side audit logging is the integrator's responsibility; the government APIs do not provide one on the caller's behalf."
},
{
"dimension": "legal_grounding",
"apier": "Obligation and deadline answers are produced by a versioned rulebook whose rules carry references to the underlying regulations, and responses state which rulebook version produced them.",
"direct_integration": "The integrator maps regulations to API behaviour themselves and tracks regulatory changes on their own."
},
{
"dimension": "error_handling",
"apier": "Upstream errors are normalised to one structured error format with machine-readable codes, an explanation, and remediation steps.",
"direct_integration": "Each government API surfaces its own error format; the integrator implements per-API error mapping and retry handling."
},
{
"dimension": "deadline_intelligence",
"apier": "Regulatory deadlines are computed in Europe/Oslo time with weekend and Norwegian public-holiday adjustment, versioned by the rulebook.",
"direct_integration": "Deadline rules must be implemented and maintained by the integrator from the published regulations; the government APIs do not compute them."
},
{
"dimension": "cross_agency_orchestration",
"apier": "One API surface spans Brønnøysund, Altinn, Skatteetaten, and NAV data behind a common envelope and a single authentication model.",
"direct_integration": "Each agency is a separate integration with its own authentication, schemas, and lifecycle."
},
{
"dimension": "maintenance_burden",
"apier": "Upstream schema and policy changes are monitored by Apier and surfaced through an append-only change archive; the consumer response contract is append-only.",
"direct_integration": "The integrator monitors each agency's changelogs and migration timelines (for example the Altinn 2 to Altinn 3 transition) and updates their integration accordingly."
},
{
"dimension": "time_to_first_call",
"apier": "Public endpoints and a zero-auth sandbox work without any government onboarding; company-data endpoints require an API key only.",
"direct_integration": "A first production call requires Maskinporten client registration plus the relevant government scope or delegation grants before any data is returned."
}
],
"methodology": "Qualitative comparison based on Apier product documentation and the publicly documented integration requirements for the Norwegian government APIs (Maskinporten, Altinn, Brønnøysund Register Centre, Skatteetaten). Quantitative performance claims (success rates, latency) are intentionally omitted until they can be backed by measured live telemetry.",
"source": [
"Apier product documentation and OpenAPI specification",
"Public Norwegian government integration documentation (Digdir/Maskinporten, Altinn, Brønnøysund Register Centre, Skatteetaten)"
],
"last_updated": "2026-06-12T00:00:00.000Z"
},
"_meta": {
"rulebook_version": "1.0.0",
"data_freshness": "2026-06-12T00:00:00.000Z",
"last_verified": "2026-06-12T00:00:00.000Z",
"source": "apier.no internal comparison",
"served_from": "static",
"schema_version": "2.0.0"
}
}
Inspect the canonical agent workflows
One entry per canonical workflow, with intent, steps, and failure modes. Mirrored for humans on /recipes.
Requestbash
curl https://www.apier.no/workflows.json
Responsejson
{
"schema_version": "1.0.0",
"workflows": [
{
"id": "get-company-obligations",
"name_en": "Get Company Obligations",
"name_nb": "Hent selskapets plikter",
"intent": "List the regulatory obligations that apply to a Norwegian company.",
"trigger_intent_en": "What does this company have to do legally?",
"expected_outcome": "An obligations array with applicable/not_applicable/insufficient_data verdicts.",
"estimated_time_ms": 350,
"requires_auth": true,
"tier_minimum": "free",
"failure_modes": ["VALIDATION_FAILED", "NOT_FOUND", "UPSTREAM_UNAVAILABLE"],
"steps": [
{
"step": 1,
"capability_id": "company.context",
"purpose": "Read the company's Tier 1 data.",
"expected_response": "data.data_tier = tier_1|tier_2"
},
{
"step": 2,
"capability_id": "company.obligations",
"purpose": "Evaluate the Rulebook against the company context.",
"expected_response": "data.obligations[]"
}
],
"agent_instructions": "Call step 1 first. If data_tier = tier_1 and step 2 returns insufficient_data for a rule, surface upgrade_path to the user."
}
]
}
