# Norway Company & Supplier Evidence (`civicdataforge/norway-company-evidence`) Actor

Receipt-backed entity and supplier evidence from the official Norwegian Central Coordinating Register for Legal Entities under NLOD 2.0.

- **URL**: https://apify.com/civicdataforge/norway-company-evidence.md
- **Developed by:** [Bryan](https://apify.com/civicdataforge) (community)
- **Categories:** Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

Pay per usage

This Actor is paid per platform usage. The Actor is free to use, and you only pay for the Apify platform usage, which gets cheaper the higher subscription plan you have.

Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-usage

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## Norway Company & Supplier Evidence

This actor produces bounded, receipt-backed company evidence from the official Brønnøysund Register Centre (`Brønnøysundregistrene`) Central Coordinating Register for Legal Entities (`Enhetsregisteret`). No API key is required.

The strongest route is an exact nine-digit organisation number. Name queries use the official bounded `navn` search with `navnMetodeForSoek=FORTLOEPENDE`; the actor never silently chooses among multiple or non-exact candidates.

### Official sources and rights

- Entity Register API v2 documentation: <https://data.brreg.no/enhetsregisteret/api/dokumentasjon/en/index.html>
- Entity endpoint: <https://data.brreg.no/enhetsregisteret/api/enheter>
- Norwegian Licence for Open Government Data (NLOD) 2.0: <https://data.norge.no/nlod/en/2.0>

The official documentation identifies the data as NLOD-licensed and documents the versioned entity media type `application/vnd.brreg.enhetsregisteret.enhet.v2+json`. NLOD 2.0 permits copying, use, modification, and distribution subject to its terms. It requires attribution and, where practical, links to the source and licence. Changed information must be identified as changed. It also excludes personal data where there is no lawful basis for disclosure and further processing.

Every result carries this attribution and change disclosure:

> Contains data under the Norwegian licence for Open Government Data (NLOD) distributed by Brønnøysundregistrene. CivicDataForge changed the information by selecting and minimizing fields and using stable English keys; Norwegian source strings were not translated.

### Privacy-minimized product boundary

This actor calls only `/api/enheter` and `/api/enheter/{organisasjonsnummer}`. It does not call public or Maskinporten-protected role endpoints.

It deliberately excludes:

- natural-person roles and personal identification numbers
- email, telephone, and mobile fields
- street address lines
- source `_links`

Business and postal addresses are reduced to country, postal code/city, and municipality. Entity legal names and historical entity names remain because they are identity evidence published on the entity endpoint, but consumers remain responsible for an appropriate legal basis for any processing that concerns a natural person.

### Input

```json
{
  "batchReference": "supplier-intake-2026-08-23",
  "maxRecords": 10,
  "queries": [
    {
      "reference": "supplier-001",
      "organisationNumber": "974760673",
      "name": "REGISTERENHETEN I BRØNNØYSUND",
      "purpose": "SUPPLIER_ONBOARDING_EVIDENCE"
    },
    {
      "reference": "name-discovery",
      "name": "REGISTERENHETEN I BRØNNØYSUND",
      "purpose": "ENTITY_VERIFICATION"
    }
  ]
}
```

`purpose` is caller-declared context and must be one of:

- `ENTITY_VERIFICATION`
- `SUPPLIER_ONBOARDING_EVIDENCE`
- `PROCUREMENT_RESEARCH`
- `OTHER`

It is recorded in the receipt but never changes source facts or produces an eligibility verdict. `maxRecords` is 1–50. A name request asks the official service for `maxRecords + 1` candidates so truncation is detected before only `maxRecords` are returned.

When organisation number and name are both supplied, the organisation number controls the exact lookup and the name is only a consistency check. A name conflict does not override the exact record; it is disclosed for review.

### Decisions

- `MATCH`: an exact organisation-number endpoint returned the requested entity, or a bounded name search reported exactly one candidate whose current name equals the submitted name after conservative Unicode/case/punctuation normalization.
- `NO_PUBLISHED_MATCH`: the exact endpoint returned the documented 404, or a complete bounded name search reported zero candidates.
- `AMBIGUOUS`: a name search did not establish one unique exact current-name candidate. Candidate records and truncation state are preserved.
- `SOURCE_UNAVAILABLE`: timeout, non-JSON response, unsafe redirect, HTTP/source failure, size breach, or malformed source structure. It is never converted into a no-match.
- `INVALID_INPUT`: missing/invalid purpose, malformed nine-digit number, empty/oversized name, invalid bounds, or invalid previous receipts. Invalid queries cause no source request.

### Evidence and receipts

Norwegian publisher strings such as organisation-form, industry, activity, and statutory-purpose descriptions are preserved with `_no` keys. They are not machine translated. Stable English keys describe field meaning only.

Each row includes:

- exact official `source_url` and `retrieved_at`
- raw-response `source_response_sha256`
- a pinned `source_schema_fingerprint` over media type, selected mappings, and explicit exclusions
- normalized records with deterministic `record_receipt_hash`
- deterministic query `decision_receipt_hash`
- shared deterministic `batch_receipt_hash`
- NLOD 2.0 rights, source, attribution, and change disclosure
- explicit scope completeness and privacy-minimization state

Retrieval timestamps remain observable metadata but are excluded from deterministic receipt payloads.

### Non-verdict boundary

Published registry status fields—including bankruptcy or liquidation fields—are copied as dated source facts. CivicDataForge does not interpret them as KYC, supplier acceptance, procurement qualification, sanctions, solvency, credit, or legal eligibility decisions. All verdict flags remain `false`.

The official source and NLOD terms provide the data “as is” without data-quality or availability warranties. Consumers should read the current official record and applicable law before consequential action.

### Local verification

```bash
npm install
npm test
npm run test:live
npm run test:actor
npm audit --omit=dev --audit-level=high
npm pack --dry-run --json
```

The offline suite covers every decision, exact/name route construction, ambiguity/truncation, response validation, unsafe redirects, oversize responses, invalid inputs, PII minimization, Norwegian-string preservation, and deterministic receipts. Live tests remain bounded to one exact organisation and one synthetic no-result name.

# Actor input Schema

## `queries` (type: `array`):

One to 25 evidence queries. Prefer the exact nine-digit organisation number. A supplied name alongside an organisation number is returned as a consistency check, never as a replacement identifier.

## `maxRecords` (type: `integer`):

Name searches request one additional record internally so truncation is detected and disclosed.

## `batchReference` (type: `string`):

Optional non-sensitive batch reference bound into the shared batch receipt.

## Actor input object example

```json
{
  "queries": [
    {
      "reference": "supplier-no-001",
      "organisationNumber": "974760673",
      "purpose": "SUPPLIER_ONBOARDING_EVIDENCE"
    }
  ],
  "maxRecords": 10
}
```

# Actor output Schema

## `results` (type: `string`):

API URL for the default dataset rows.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "queries": [
        {
            "reference": "supplier-no-001",
            "organisationNumber": "974760673",
            "purpose": "SUPPLIER_ONBOARDING_EVIDENCE"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("civicdataforge/norway-company-evidence").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "queries": [{
            "reference": "supplier-no-001",
            "organisationNumber": "974760673",
            "purpose": "SUPPLIER_ONBOARDING_EVIDENCE",
        }] }

# Run the Actor and wait for it to finish
run = client.actor("civicdataforge/norway-company-evidence").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "queries": [
    {
      "reference": "supplier-no-001",
      "organisationNumber": "974760673",
      "purpose": "SUPPLIER_ONBOARDING_EVIDENCE"
    }
  ]
}' |
apify call civicdataforge/norway-company-evidence --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,civicdataforge/norway-company-evidence"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/L9veafufAtLFNgiWP/builds/mnKblLCjPc0BdqrME/openapi.json