Introduction

Publicly accessible, but undocumented, HTTP endpoints are frequently used by Norwegian newspapers and commercial providers to display real estate transaction information. Because these endpoints are not designed as public APIs, they require empirical exploration. The present investigation focuses on two distinct systems:

1. API.no, a REST interface used by several newspapers to expose a legacy transaction dataset.

2. Webatlas WAAPI, an authenticated interface used to retrieve historical ownership chains for individual cadastral units.

Both systems expose structured JSON, but with different conceptual models. API.no delivers per-transaction objects filtered by temporal criteria, while Webatlas delivers full history for a specific cadastral identifier (gnr, bnr, fnr, snr). The aim of the study is to describe their structure, identify canonical URL forms, and outline how the gid is systematically constructed.

Methods

API.no Endpoint Inspection

API.no exposes legacy property transactions through the endpoint:

https://services.api.no/api/acies/v1/custom/PropcloudLegacyTransaction

The API accepts filtering parameters encoded as equal=, greaterThanOrEqual= and lessThan=. Empirical testing shows that the service follows a strict pattern for both county-level and municipality-level filtering.

County-Level Filtering

A county is specified using a two-digit countyCode:

?equal=countyCode:XX

Dates are constrained with:

&greaterThanOrEqual=date:YYYY-MM-DD
&lessThan=date:YYYY-MM-DD

Combined:

https://services.api.no/api/acies/v1/custom/PropcloudLegacyTransaction
    ?equal=countyCode:50
    &greaterThanOrEqual=date:2021-01-01
    &lessThan=date:2022-01-01

Municipality-Level Filtering

Municipalities use a four-digit municipalityCode:

?equal=municipalityCode:5001

The date constraints function identically. The returned JSON is an array where each object constitutes a single registered property transaction.

Structure of API.no JSON

Empirical analysis of returned objects confirms a stable schema including:

• Geographic coordinates.

• A list eiendommer, each representing one cadastral component.

• A set of transaction-level attributes such as:

  • dokumentnummer

  • dokumentdato

  • omsetningstype

  • omsetningsbeloep

• Nested lists selgere and kjoepere, each containing one or more entities.

This structure means one transaction may contain several cadastral units, and therefore several eiendommer entries.

Webatlas WAAPI Access Through curl

Webatlas exposes a structured history endpoint of the form:

https://waapi.webatlas.no/api/propertyhistory/{gid}

A bearer token is required:

curl -H "Authorization: Bearer <TOKEN>" \
     "https://waapi.webatlas.no/api/propertyhistory/50010041403530000000"

The key finding is that the endpoint accepts a single value gid, which uniquely identifies a cadastral object in the Norwegian matrikkel. No temporal filtering is necessary; the endpoint always returns the full known transfer history.

Construction of the Webatlas gid

Inspection of the returned JSON, combined with review of the URLs used by newspaper property pages, confirms that the gid is a fixed-length concatenation of five integer components:

\[\texttt{gid} = \texttt{KKKKGGGGBBBBFFFFSSSS}\]

where

\[\begin{equation} K : \text{kommunenummer (4 digits)} \end{equation}\]

\[\begin{equation} G : \text{gardsnummer (4 digits)} \end{equation}\]

\[\begin{equation} B : \text{bruksnummer (4 digits)} \end{equation}\]

\[\begin{equation} F : \text{festenummer (4 digits)} \end{equation}\]

\[\begin{equation} S : \text{seksjonsnummer (4 digits)} \end{equation}\]

Thus:

\[\texttt{gid} = \text{sprintf("\%04d\%04d\%04d\%04d\%04d", K, G, B, F, S)}\]

For example:

\[\texttt{kommunenummer} = 5001,\quad \texttt{gnr} = 414,\quad \texttt{bnr} = 535,\quad \texttt{fnr} = 0,\quad \texttt{snr} = 0\]

becomes:

\[\texttt{gid} = 50010041405350000000\]

Padding to four digits is mandatory. Without zero-padding, the endpoint returns either HTTP 404 or inconsistent results.

Structure of Webatlas JSON

Each returned object is a list of transfer events. Each event contains:

• A top-level coordinate pair (longitude, latitude).

• An array eiendommer, typically containing a single cadastral object.

• A complete set of transaction descriptors:

  • dokumentaar

  • dokumentnummer

  • omsetningstypeKode

  • omsetningsbeloep

• Nested selgere and kjoepere lists.

Unlike API.no, Webatlas always returns the entire history for this single gid. If the cadastral unit has been subdivided or merged in the past, all registered events still appear attached to that identifier.

Results

Inspection of both systems reveals a clear contrast in design. API.no organizes data by temporal slices, returning all transactions matching given dates and administrative codes. In contrast, Webatlas focuses on individual cadastral units, returning their full historical sequence regardless of date.

Both systems use similar interior JSON structures for buyers, sellers, and cadastral information, but differ fundamentally in granularity.

The GID construction rule is fully deterministic and reproducible, enabling systematic enumeration of all cadastral objects when both gnr and bnr are known.

Discussion

The investigation shows that Norwegian real-estate data - even when not officially published as open APIs - is internally consistent and structured. API.no can be understood as a time-indexed transaction source, while Webatlas offers object-indexed history. The deterministic GID pattern provides a reliable method for requesting property histories.

The JSON structures in both systems are rich enough to support external processing, such as deduplication, aggregation, and longitudinal analysis. Although neither system provides formal documentation, their behaviour is predictable when analysed systematically.

Home | Privacy Policy