Category
Data, or proof?
A company-data API gives you registry facts: that a company exists, who holds roles, NACE codes, status. That is a different job from proving later what those facts were, where they came from and when they were read.
What a company-data API gives you
Lookups: that a company exists, its entity type, NACE codes, status, roles and signing authority. Valuable facts, but still just facts. They tell you what is true now, not what was true when your agent acted.
What proof requires
- Signing authority as coded. Signing authority and prokura exactly as Brønnøysundregistrene code them, uninterpreted, so your agent applies the rules itself.
- Source and time. Every answer names the register it came from and the time it was read, in a _meta block your agent can store.
- Deadlines and obligations. What is due, when, and in Oslo time, derived rather than guessed.
- Receipts and audit trail. A signed receipt you can verify offline and a daily externally anchored archive, so you can show what was checked, and when.
Apier is the proof layer
Apier builds on the registries rather than replacing them. As a category, the difference is simple: a data API answers “what is true?”, while Apier also answers “where did that come from, when, and can I prove it later?”. If you would rather build that layer yourself, we have laid out the maths.
Related pages
- Direct integration vs Apier — build the stack yourself vs use Apier.
- Brønnøysund (BRREG) API — the company-data source itself.
- What is KYB and how does it work in Norway? What a company-data vendor is usually sold as.
- What is Brønnøysundregistrene? The registry underneath every such vendor.
- Pricing and the documentation.
Get started
Try the company-data endpoints in the sandbox with no signup, or read the documentation.