Grouped by the question they answer. Everything below the prose — inputs, types, values, what is required — is read off the running server's own schema.
Find the property
Every question about one property starts here. One address, key or finnkode in — the property, its level and the keys the other tools need out — and, with a key in hand, what physically stands on the ground.
Find the property
The first hop for anything about one specific property. Give it an address, a matrikkelnummer, a new_unitkey, a finnkode or a registerenhet id; get back the property, the level it sits at, and the keys every other property tool needs.
When to use it Before get_owners, get_conveyances, get_encumbrances and get_innsyn_cases. It is for one known property — to find a set of properties you do not know yet, use search_properties.
What comes back next is the part you carry on: each entry there is a finished argument object for the tool it is named after. Pass it through unchanged. One address is often many units — Drammensveien 54B is 14 seksjoner — so address_match names the entrances covered and the neighbouring entrances deliberately excluded. address_status separates a resolved address from a property that has none registered, which is a fact about the plot rather than a gap in the data. A unit's area comes twice and the two often differ: bruksareal is what the matrikkel registered, while bra_i_m2 is the area Solgt values the home over — for a home that has been advertised, the advert's figure the owner knows, with soverom and the advert itself in siste_annonse. A unit Solgt holds no record of carries none of the three.
Hands off to get_avm get_comparable_sales get_conveyances get_encumbrances get_innsyn_cases get_owners get_price_index get_property_facts get_property_tenancy
↳ adresse-til-eier · ↳ eiendom-til-saker · ↳ eiendom-til-heftelser · ↳ nokkel-uten-fem-ledd
About — needs exactly one of address · new_unitkey · unitkeys · registerenhet_id · finnkode · matrikkel
Find the property
What is actually there, as the matrikkel records it: the buildings standing on the property with their type, floor area and floors, everything that has been built onto them, any rental listing or parking registered on it, and the date it last changed hands.
When to use it Every other tool on this spine answers what is REGISTERED AGAINST a property — owners, heftelser, overdragelser, kommunale saker. Name the property either way: an { address } (or { finnkode }), which the tool resolves itself in one call, or the keys out of a next block when you already hold them. A house letter is an ENTRANCE, never a seksjonsnummer. This one answers what stands ON it, which is the question behind "hvor stort er bygget", "hvor gammelt er det" and "har det blitt påbygd". It takes up to 25 keys, copied out of a next block: resolve_property, search_properties and search_commercial_properties all hand it the same five-segment keys. Ask it at whatever level you have — a seksjon or a borettslagsandel is answered from the matrikkelenhet it belongs to, because that is where buildings are recorded, so you do not have to climb to the parcel yourself. get_property_tenancy does not do that and wants the parcel key. For a single home's own floor area read bra_i_m2 on its resolve_property row or use the market tools, not this one.
What comes back answered_from is the first field to read. parent_parcel means the key you asked about is a seksjon or an andel and every number below therefore describes the WHOLE property: a 3 879 m² building is the block, not the flat in it. Area arrives as three labelled numbers rather than one — bruksareal_totalt_m2 is bolig plus annet — and a building the register never measured comes back with areal_status: "ikke_registrert" and nulls, never 0 m², which is the case for over a third of all buildings. etasjer[] breaks that total down; it is never added to it. "Har det blitt påbygd?" is endringer[], and the field that decides the answer is utfall: only gjennomfort was built, bortfalt is an application that was cancelled or a building that is gone, and Ombygging is an internal rebuild that adds no area at all. A property with no registered building is a complete answer — an ubebygd tomt — not a failed lookup. Rental listings come from two sources that are measured to disagree in both directions, so an empty one proves nothing about the other. siste_eierskifte is one date and one omsetningstype, a headline rather than a history — the transfers themselves are get_conveyances. And fredet or sefrak on a building is a real constraint on what an owner may do to it, so say so rather than listing it as a flag.
Reached from resolve_property
↳ hva-star-pa-eiendommen · ↳ er-det-paabygd
About — needs exactly one of unitkeys · address · finnkode
Find the property
Find properties in a municipality, several municipalities, a county or the whole country without knowing which ones: filter by type, seksjonering, bydel or a named område inside the kommune (delområde/grunnkrets — every kommune has them, bydel only six cities do), gårdsnummer, what the buildings are used for, what kind of buildings they are, whether the owner is a company or a private individual, and how many dwellings, owners and square metres of floor area the property has.
When to use it resolve_property answers about one property you can already name; this one produces the set. kommune takes one municipality or a list, fylke a county, and neither means all of Norway — where a property_type is required, because it is the only index that bounds a national query. mode: "count" counts in the database without reading a single row, which is the cheap way to size a question before you ask it, and works at every scope. mode: "rows" is one page and needs a kommune or fylke; so does naringsgruppe, in every mode, while bygningstype has its own national index and works everywhere. mode: "dataset" is the answer to «gi meg alle»: the whole matching set stored as a file the app renders, up to 12 000 rows, with a small envelope back — ask for it instead of paging. Landbrukseiendommer are reached through naringsgruppe: "landbruk"; blocks of flats through bygningstype: "boligblokk" — a family name that expands to the SSB building-type codes on the server (enebolig, tomannsbolig, rekkehus, boligblokk, fritidsbolig, garasje_uthus, kontor, forretning, industri, lager, landbruk_fiske and the rest; a code or a range is accepted too), which is how «bygårder som er boligblokker» is separated from the rekkehus and garages the bygård type also holds. «Minst 4 boligbruksenheter og maks 2 eiere» is min_bruksenheter: 4, max_eiere: 2 in the call — a bound on the registered dwelling count, the registered owners of the matrikkelenhet, or the summed floor area (min_bra/max_bra, m²) — and like naringsgruppe these read every property in scope, so they need a kommune or fylke. How many properties an owner holds is not a filter here — that is get_owner_portfolio, per owner. «I Kvadraturen», «på Lund», «i sentrum» inside a kommune is omrade — a named area matched on the server against the SSB delområde and grunnkrets recorded on nearly every built-on property (the answer says how many in the kommune carry none), which is the sub-kommune level everywhere bydel has nothing (bydel exists only in Oslo, Bergen, Trondheim, Stavanger, Drammen and Bodø). A delområde carrying the word takes the whole delområde; otherwise the grunnkretser that do; and the answer's omrade says which it settled on, with their grunnkretser, so the next call can name the exact ones. A name nothing carries matches nothing and lists the delområder there are — never the whole kommune in the area's place. gnr is the same narrowing by gårdsnummer when the user gives a number. Both need exactly one kommune.
What comes back Rows carrying the complete new_unitkey, the address, the delområde and grunnkrets the property sits in, the distinct building-type codes on the parcel, the dwelling and owner counts, the summed bruksareal with a bruksareal_status saying whether every building was measured, and a plottable point — or just the numbers when you count, or a dataset envelope when you asked for the whole set. Read dekning before you describe a filtered result as complete: a property with no registered building, owner, bruksenhet or measured area cannot be assessed by that filter at all, so the match is a minimum, not the full set — and an upper bound (max_eiere, max_bra) never counts the unregistered as 0.
Hands off to get_owners
↳ landbruk-i-kommunen · ↳ bygaarder-med-faa-eiere
About — needs at least one of kommune · fylke · property_type
mode:"rows" additionally needs a kommune or a fylke; næringsgruppe does too, in every mode, and so do the min/max_bruksenheter, min/max_eiere and min/max_bra bounds; omrade and gnr need exactly one kommune
Find the property
What lies around a property, and how far it really is: the three nearest of each kind of place — bus, train, tram, metro, ferry, airport, university, school, kindergarten, supermarket, mall, department store, convenience store, ski resort, shore, lake, city — with the walking and driving distance routed along the actual network, not drawn as a straight line.
When to use it After resolve_property has produced the key: it takes unitkeys (1–10) copied verbatim from resolve_property.next or a search row, and both key shapes work. types narrows to any of the 17 and should be set when the question is about one thing ("hvor langt til T-banen?" → ["metro"]) or about several properties at once. get_property_facts is what stands ON the property; this is what stands AROUND it.
What comes back Three distances per place, and the routed ones are the answer: air_m is the straight line, walk and drive follow the footpath and road network, and they part ways wherever water or terrain is in between — 82 m of air but 855 m on foot to Slependen stasjon is a measured row. walk_detour_ratio (walk ÷ air) makes that visible. There is no public-transport journey time here. Only the three nearest per type are stored, so found says how many exist within radius_m and withheld how many you are not seeing; a subtype question — the nearest barneskole, the nearest Rema 1000 — cannot be settled from it, only what the three nearest schools or supermarkets are. Each type has its own radius_m (bus 3 000 m, shore 1 000, lake 2 000, tram 5 000, metro 10 000, train and ferry 50 000; city unbounded), so found: 0 means none within that radius, never none in Norway. status separates ok, empty (searched, nothing within radius — a real finding) and partial (a key with no enrichment row, named in keys_not_enriched — unknown, not empty; coverage is a minority of all units but ~99 % of active listings). Read updated_at on every row: the corpus is not refreshed daily.
↳ hva-ligger-i-naerheten
Who owns it
The registered owner today — from the property, or the other way round, from a name to everything that party holds.
Who owns it
Who is registered as owner today, for up to 25 properties at a time — straight off the matrikkel/grunnbok spine.
When to use it Name the property either way: an { address } (or { finnkode }), which the tool resolves itself in one call, or the keys out of a next block when you already hold them. A house letter is an ENTRANCE, never a seksjonsnummer. For «hvem eier», and for «hvem er hjemmelshaver» too — hjemmelshaver is the grunnbok's own word for the party this returns, not a separate one. This is the present tense. Who owned it before, and what was paid, is get_conveyances. Going the other way — from a name to the properties — is resolve_owner followed by get_owner_portfolio.
What comes back Name, share, ownership form and a safe identification number: a company's organisasjonsnummer in full, a private individual's national ID never. For a company you also get organisasjonsform, status and one level of beneficial ownership from the aksjonærregister. Rows are CURRENT holders only: every row is checked against the grunnbok's own transfers of that property, a party recorded as having sold it is left out and counted in owners_retired, and a holder whose purchase is on record carries gjeldende_fra, the tinglysingsdato — absent when the holding predates the digital grunnbok, never a guess. owners_status carries four different answers, and owned_at_unit_level is the one that trips people up: a sameie or borettslag has no owner of its own, because it is owned seksjon by seksjon, and owned_units.unitkeys says where to ask instead.
Reached from resolve_property search_properties search_property_holdings
↳ adresse-til-eier · ↳ eier-pa-feil-niva
About — needs exactly one of new_unitkey · unitkeys · address · finnkode
Who owns it
A name in, the parties that actually exist out. It resolves companies and private individuals alike, because grunnbok ownership is public record.
When to use it Whenever you have a name rather than an identifier. An organisasjonsnummer cannot be derived from a name, so resolve it here first; private individuals resolve the same way, because grunnbok ownership is public record.
What comes back Read resolution first, because a name is not an identity and that is the normal case: unique (one party, next is filled in), ambiguous (several — next is empty on purpose, so ask which), narrowing_required (too many private individuals to list; ask for a municipality) or not_found. Each candidate carries holdings.total and holdings.kommuner so the choice can be put to a human meaningfully. A name written with initials («Andreas S. Wöllert») is expanded against the register when no exact spelling matches. A candidate marked has_disposals holds nothing today but used to — a FORMER owner, whose next aims get_owner_history instead of the portfolio: the call for «hva har de solgt, og hva fikk de for det». Zero holdings plus that hop means «eier ingenting NÅ»; follow it before concluding anything about ownership, and name the last sale.
Hands off to get_owner_history get_owner_portfolio
↳ navn-til-portefolje · ↳ avvist-fodselsnummer
Who owns it
A group name in, every company in the konsern out — and what they all own, counted as one portfolio. A Norwegian property group is a holding company plus a fan of single-purpose companies whose names carry no trace of it; the portfolio is the union of all of them.
When to use it Whenever a user names a property company, a landlord or a chain and asks what "they" own. resolve_owner answers a different question — which single party carries this name — and live it resolves HEIMSTADEN AS, which owns nothing directly; answering from that alone reports 0 properties for a landlord holding thousands. If you are about to say "de eier ingenting" or to ask for a subsidiary's organisasjonsnummer, this is the tool you wanted. It takes one name, matched as a prefix on the company register and on the registered group parent. The properties themselves are the same call: mode: "rows" lists them a page at a time with the holding company on every row, mode: "dataset" stores the whole list as a file the calling application renders — «vis alle eiendommene til Olav Thon» is one dataset call, never one get_owner_portfolio per company — and kommune scopes the count and the list alike.
What comes back Two levers, both reported: via: "navn" is a company whose own name carries the group name, via: "konsern" one whose registered group parent does while its own name gives no hint — listing only the first understates the portfolio. group.total is the whole group's property count (parcels + sub_units) summed over every company matched, and group.holding_companies how many of them hold anything at all. A null konsern_topp_orgnr is normal: the parent is foreign and has no Norwegian organisasjonsnummer. matching says whether spelling was forgiven — under exact an empty answer may be a typo. Read the notes before summing: a broad name can match companies that merely share a prefix, and the notes say so. Every company row carries next.get_company and next.get_owner_portfolio, so the drill-down is a copy, never a number assembled by hand. In rows mode properties carries the page and total the whole list, each row a portfolio row plus eier; a dataset answers with the envelope, its coverage.kilde_dekning naming how many companies the group had and how many hold property.
Hands off to get_company get_owner_portfolio
↳ hele-konsernet
Who owns it
Everything the registers hold about one company, by organisasjonsnummer: master data, the latest annual filing, the dated shareholder register (2020–2025), current board and auditor roles, its subsidiaries, and how much property it holds.
When to use it After resolve_company_group or resolve_owner has produced the orgnr — those two resolve a name, this is the drill-down for the company itself. Its next block carries ready-made calls for the Norwegian parent and up to ten subsidiaries, so a corporate group can be walked hop by hop without assembling a single number by hand.
What comes back aksjonaerer is dated: one entry per register year, newest first, each carrying register_aar, and the register covers 2020 through 2025 — nothing older exists. Holder identities are re-derived rather than read, because the source types every holder without a Norwegian organisasjonsnummer as a person, foreign companies included: holder_form separates selskap, privatperson, utenlandsk_selskap and ukjent, and ukjent means undetermined rather than a private person. A person is identified by name and birth year only. regnskap is the latest filing rather than a series, so no trend can be read from it, and its own status separates a company that files nothing from a filing we could not fetch. A null konsern.topp_orgnr next to topp_er_utenlandsk: true means the group parent has no Norwegian organisasjonsnummer — the normal shape for the large landlords, not a gap.
Hands off to get_owner_portfolio
Reached from get_owner_portfolio resolve_company_group
↳ selskapskortet
Who owns it
Everything a party is registered on right now, paged, with the whole portfolio counted even when only a page is shown.
When to use it Takes an organisasjonsnummer or a grunnbok_id — both come from resolve_owner. It answers "what does X own", which get_owners cannot.
What comes back total is the whole portfolio, shown is this page — never report the page as the total. Rows are CURRENT holdings: each is checked against the grunnbok's own transfers of that property, a property the party is recorded as having sold is left out and counted in properties_retired, and a row whose purchase is on record carries gjeldende_fra, the tinglysingsdato; when only a page was checked, total is a ceiling and the note says so. A seksjon or borettslagsandel is recorded on the parent matrikkelenhet's document, and read_from says so; that parent's own owner is a different party and is not part of this portfolio. For a party addressed by grunnbok_id, selskaper adds what the aksjonærregister records them as holding shares in — a yearly snapshot, dated by synced_at, each company with how many properties it is registered on and its own next.get_company and next.get_owner_portfolio hops, which is how «direkte eller indirekte» is answered without assembling an organisasjonsnummer by hand. Its section status keeps three answers apart: holdings, a party the register indexes and lists nothing on (empty), and a party the register does not reach at all (not_found) — the last is never «eier ingen selskaper». A company addressed by orgnr skips it; its holdings are get_company's datterselskaper.
Hands off to get_company
Reached from get_company resolve_company_group resolve_owner
↳ navn-til-portefolje
About — needs exactly one of orgnr · grunnbok_id
Who owns it
The filed annual accounts for up to 25 companies in one call: revenue, operating result, net result, equity, total debt, total assets and the equity ratio. Built for portfolios, where the question is how solid a fan of single-purpose companies is rather than how one of them did.
When to use it After search_companies, resolve_company_group or any tool that hands back organisasjonsnummer — copy next.get_company_financials through unchanged. get_company is the drill-down for ONE company and carries the shareholder register, board roles and subsidiaries beside the accounts; this is the accounts alone, in bulk. It takes nine-digit organisasjonsnummer only: an eleven-digit number is a fødselsnummer and is refused rather than looked up.
What comes back A SNAPSHOT, not a series, and the answer says so before anything else: 440 346 of the 444 803 companies in the source have exactly one filed year, so no trend, growth rate or direction can be read from these figures however they are arranged. aar is the FISCAL year, verified against the filed period, and it DIFFERS BETWEEN COMPANIES — filing is staggered, with 416 413 rows on FY2025, 25 155 on FY2024 and 3 589 still on FY2023 — so it rides every company rather than the answer, and regnskapsaar counts the spread. foreldet_regnskap flags a company three years or more behind the calendar year, which means at least one whole filing cycle was missed; it is a soft signal and never a conclusion, because a dormant company looks identical. omsetning_kilde separates a filed revenue figure from a zero the accounting identity proves (Brønnøysund omits the field instead of writing 0) from a genuine unknown, which is what keeps a property SPE with no operating revenue visible as the ordinary thing it is rather than as a warning. Every figure carries its own valuta — 1 205 filings are in USD, EUR, SEK or one of eleven others — so nothing may be added to a kroner total without checking it. The debt split is deliberately absent: 97.7 % of companies file abbreviated accounts and long-term debt is missing from over half of them, which is exactly where a landlord's mortgage would sit, so sum_gjeld carries the total and an absent long-term figure never means debt-free. A company with no numbers is not a failed lookup — regnskap_status says which of four it is: filed but not yet mirrored, does not file at all, could not be fetched, or not assessed.
Reached from search_property_holdings
What it has been through
Registered transfers: who sold to whom, when, and for how much — and the same question asked of a party rather than a property.
What it has been through
Every tinglyst overdragelse on a property, newest first: date, omsetningstype, vederlag, dokumentavgift, fellesgjeld where recorded, and the buyers and sellers.
When to use it Name the property either way: an { address } (or { finnkode }), which the tool resolves itself in one call, or the keys out of a next block when you already hold them. A house letter is an ENTRANCE, never a seksjonsnummer. A parcel and its seksjoner have separate histories and neither contains the other, so ask at the level the question is about.
What comes back A transfer without a price is normal — gave, arv, uskifte, fusjon and old registrations carry no vederlag. It comes back as price: null and is never a sale for 0 kroner. Every amount names its currency. totals counts for you, including the split by omsetningstype, so nothing has to be summed across rows. And a price is what someone paid on a date; it is not a valuation.
Reached from resolve_property
↳ overdragelser
About — needs exactly one of unitkeys · address · finnkode
What it has been through
The screen the single-property history cannot do: every tinglyst overdragelse in a kommune of a given kind in a date window — arv, tvangssalg, gave, fritt salg — one row per transfer, newest first, with the property, its address, the price where one was recorded and the parties as the grunnbok names them. Counted, it also ranks the parties: who bought or sold most in the window.
When to use it For «finn nylig arvede boliger i Oslo», «dødsbo i Frogner siste måned» or «hvor mange tvangssalg i Bergen i juli». get_conveyances is the history of one property you already hold the key to; this finds the properties from the kind of transfer. The register has no «arv» code — an inheritance is tinglyst as Skifteoppgjør (the estate settled and passed to the heirs) or Uskifte (the surviving spouse took it over undivided), and omsetningstype: ["arv"] selects both. The cost is the kommune times the window: the scan rides a kommune-plus-date index, but every document with a transfer in the window is read whole. fra is required, at most 366 days fit one call, and next.search_conveyances carries the previous period so a decade is walked a year at a time. mode: "count" is exact and never capped, with group_by over omsetningstype, eiendomstype, kommune or bydel — or group_by: "kjoper" / "selger" for a ranking of the parties: «hvem kjøper mest eiendom i Nordre Follo i 2026», «hvilke aksjeselskaper kjøper flest eiendommer» is mode: "count", group_by: "kjoper", kjoper_form: "selskap", and rangering names the top 25 by number of tinglyste kjøp — a document conveying 13 seksjoner is one purchase (antall_dokumenter), the units stand beside it (antall_eiendommer), each deal's price is summed once — with orgnr for companies; «selskap» is every organisasjonsnummer holder, a borettslag or a kommune as much as an AS. That is who BOUGHT in a period; who owns most today is search_property_holdings. Two more groupings are series: group_by: "kjoper_form" splits the window by the buying side — selskap, person, blandet, annet — with the share of each («hvor stor andel kjøpes av selskaper»), and group_by: "maaned" is the count and kroner sum per month, every month of the window present («hvordan har omsetningen utviklet seg gjennom året»). kjoper_form and selger_form («selskap» or «person») also narrow a rows answer, and every grouping, to transfers with a company or a private individual on that side; mode: "rows" pages up to 5 000 transfers; mode: "dataset" stores the whole window as a file the calling application renders. «Tvangssalg i Bergen» is omsetningstype: ["tvangssalg"] here: the register holds the forced sales that were tinglyst, and a sale only announced or begjært is in no register this surface reads — the answer says so beside the list. An utlegg is not a tvangssalg; utlegg are read per property, in get_encumbrances.
What comes back One row is one TRANSFER, so the same property can appear twice in a window — antall_eiendommer counts the unique ones and a lead list de-duplicates on new_unitkey. Dates are tinglysingsdato, which can lag the agreement by weeks. A transfer without a price is normal (arv, gave, uskifte and fusjon carry no vederlag), comes back as price: null and is never a sale for 0 kroner; a price filter keeps only transfers with a recorded figure. On an arv row the buyers ARE the heirs, named as the grunnbok names them, each with a kind; no fødselsnummer is ever returned. A party ranking (rangering) orders by tinglyste dokumenter — a document that conveyed three seksjoner is one purchase with three units — sums each document's vederlag once, in kroner only, attributes it to every party on the document, and names private parties by name and grunnbok id, never a number; a løpenummer holder (dødsbo, foreign persons) is form «annet». address is resolved through the same resolver resolve_property uses and address_status says why it is null when it is — the key is always complete. next carries get_conveyances and get_owners for the page's properties, and the previous window for this tool.
What it has been through
What a party used to hold, and whether they actually let go of it.
When to use it The past-tense twin of get_owner_portfolio. Same party selector, opposite question.
What comes back holding_status is checked against the current-owner index: sold means they are out, still_owner means they are not and must never be described as a former owner. A party with no registered disposal comes back empty — that is a finding, stated plainly, not a lookup that failed.
Reached from resolve_owner
↳ tomt-er-et-funn
About — needs exactly one of orgnr · grunnbok_id
Businesses and premises
Which properties a kind of business operates from — and the same question from the other end: which businesses are registered on one property, who runs them, and who owns the building they stand in. Plus the two set tools that answer about the businesses THEMSELVES rather than about a property: which companies sit in a catchment and how big they are, and the registered parking around them.
Businesses and premises
Every property a kind of business operates from, with who runs the shop, who owns the building and who owns them. search_properties finds properties by what the register records about the property itself; this one finds them by the business standing on it.
When to use it The way in is what the business DOES or the name over its door; a question that starts from who OWNS the næringseiendommer — SPV and portfolio structure, related-party tenants, «hvem eier mest» — belongs to search_property_holdings instead. Two ways in, at least one of them required, and they are different questions rather than two spellings of one. naeringskode is what the business DOES — the register's own NACE code: grocery 47.11, pharmacy 47.73, car dealership 45.11, gym 93.13 — while brand is the name over the door. Nationally 47.11 matches 6 140 businesses on 4 815 properties, and 2 031 of those properties carry none of the named chains, so "every grocery shop" and "every chain shop" are different sets with different answers; passing both intersects them. mode: "count" is the one that answers a national HOW MANY — businesses, properties, and the distribution by kommune or kjede — in about a second. mode: "rows" returns the property rows a page at a time and requires a kommune or a fylke: a national row extract is around 4 800 properties, which no single response can carry, so it is refused rather than paged. mode: "dataset" is the route for the complete list, national included: it runs the whole scope, stores the full row set as a dataset the calling application renders directly, and returns a small envelope — columns, counts, a 5-row preview and the caveats — from which the rows must never be retyped. A caller without a dataset-rendering surface assembles the same list by walking the 15 fylker, each call bounded and its total exact. group_by: "leieforhold" is the one distribution that costs something — it has to resolve the deed and both ownership chains for every property in scope — so it runs in count mode inside a kommune or fylke, in a second or two, and is refused nationally. It covers the whole scope; the tenancy_summary on a rows answer counts only that page. And group_by belongs to counting: a rows answer refuses it rather than quietly ignoring it, and a dataset — which carries the rows themselves — refuses it too.
What comes back Five parties, kept apart. The question a commercial answer exists to settle is whether the operator and the landlord are the same interest, and that cannot be asked once they have been flattened into one "owner": driftsselskap runs the shop, leietaker_kjede is the brand over the door, morselskap is the operator's parent, spv is the party holding the deed, and overste_eier sits at the top of that party's share chain. leieforhold is derived from those ownership links rather than read from a lease — there is no commercial tenancy register behind it — and its five values are five different statements: selveier (the operator's parent IS the registered owner), nærstående (different legal entities, but both chains pass through the same company, which naerstaende_via names), ekstern utleier (both chains resolved and share nothing), eierkjede uoppløst (the chain could not be resolved at all — the absence of a finding, and not an arm's-length landlord) and ukjent (no registered owner to start from). overste_eier carries the date its source was last checked and an entydig flag; false means the chain ends in several equal holders, so the name shown is one of them rather than an established controlling owner. tied_holders counts the level-pegged holders when entydig is false; it is a number, not a list of names. On is_top and no_owner_by_type the navn is empty by design, because the top is the party already named in spv. It also carries a status, and only one of its four values is a gap: resolved names an owner above the landlord, is_top means the landlord IS the top — a private person holding the deed, or a public body, since nothing owns a kommune — no_owner_by_type means nothing owns it by construction (borettslag, sameie, stiftelse, samvirke, forening), and only unresolved is genuinely unknown, with grunnlag naming the ground in each case. evidens names which registry field settled it — hjemmel when the matrikkel recorded a fødselsnummer, so the holder is a natural person and the chain ends there, organisasjonsform when Brreg's own form code answers it, konsernrollup when a chain was resolved, and null when nothing did. Every one of those is a registry field: ownership is never inferred from a næringskode, a company name or an address, so an AS filing «Aktiviteter i borettslag og boligsameier» stays unresolved rather than being assumed resident-owned — it may equally be owned by a kommune or a holding company. Two grounds are not the same claim: ikke_i_aksjonaerregisteret means the share register does not hold the company, while eierkjede_ikke_slatt_opp means this particular answer did not walk it — a mode: "dataset" list reads the maintained rollup and skips the walk, and on the nationwide grocery list 177 of the 259 companies left unresolved are in fact in the register with shareholders on file. Measured nationwide on dagligvare, four of every five rows that used to read «Ukjent» were one of the first three, so treating the status as a single unknown throws the answer away. bra.m2 is every building on the property and not the shop's own floor area — a grocery on the ground floor of a block of flats reports the block. And read dekning before calling a list complete: a business with no matrikkel link is missing from the rows rather than absent from the market, which is 869 of the 6 140 in the national grocery count below. Each party that files accounts carries them under regnskap — the landlord (spv), whoever sits at the top of its chain (overste_eier) and the operator's parent (morselskap), but never driftsselskap, because a sub-unit files none of its own. That is what answers whether a landlord can carry the building: egenkapitalandel_prosent with the raw egenkapital and sum_eiendeler behind it, omsetning and aarsresultat, and negativ_egenkapital for the case that matters — on one page of Bergen groceries, four landlords report equity below zero, one of them at −188 % of assets. Read four things before quoting a figure. regnskap is an ARRAY, one entry per fiscal year, each carrying its own aar: today almost every company has exactly one year, so there is no trend to read and none is offered. aar is the FISCAL year and not the filing year — 183 companies already file a 2026 period that runs to February or March — so periode is what makes two companies' years comparable. omsetning_kilde separates a filed figure from a zero the accounting identity implies (Brønnøysund omits the field rather than writing 0, in 84 374 documents) from a genuine unknown, which is how a dormant holding company stays visible instead of rendering as a dash. And status is about the FILING, not about us: leverer ikke is a registered fact about the company, ikke hentet is a failure at Brønnøysund that says nothing about it, and the two must not be read alike. The figures are always the company's own — the source holds no consolidated accounts at all, so a parent's balance sheet is not its group's. A mode: "dataset" answer carries none of that row shape inline. It is a small envelope: dataset_id, the stored object's path, created_at, the resolved scope, the nine columns (matrikkelnummer · adresse · leietaker(e) · postnummer · kommune · øverste eier · hjemmelshaver (SPV) · tomtestørrelse · BRA), row_count, coverage — with kolonner_med_hull naming each column that has holes and how many — a preview of at most five rows, and merknader. The merknader are part of the answer, not debug output: they carry the same traps in dataset form (BRA is the whole building, a samvirke has no top owner, tenancy is inferred), and the businesses without a matrikkel link are counted in the envelope and named one by one in the stored manifest — never dropped silently.
Hands off to get_property_tenancy
↳ naering-eller-kjede · ↳ butikk-til-utleier · ↳ leieforhold-i-kommunen · ↳ hele-landet-som-rader
About — needs at least one of naeringskode · brand
mode:"rows" additionally needs a kommune or a fylke
Businesses and premises
The one set tool that returns COMPANIES rather than properties: which legal entities are registered in a catchment, how many people they employ, what they do, how old they are and whether they can be reached. It never touches the matrikkel and never says who owns a building.
When to use it Reach for it on a question about businesses — the tenant pool for an office building, the employer mix of a kommune, how many firms of a given kind exist and how big they are. search_properties finds properties by their matrikkel attributes, search_commercial_properties finds properties by the business standing on them, and search_property_holdings finds næringseiendommer by who owns them — all three answer with a property. This one answers with the company, so if the user wants buildings it is one of the other three. At least one indexed selector is required in every mode — a næringskode, a geography, or an organisasjonsform — because employee count, age and status carry no index and would turn the query into a scan of the whole 1.17-million-row enhetsregister; the refusal names the routes that work. mode: "count" answers nationally, with group_by over kommune, næringskode, size band or legal form. mode: "rows" returns the companies a page at a time and requires a geographic scope. mode: "dataset" runs the whole scope and stores the full set as a file the calling application renders, returning a small envelope the rows must never be retyped from. kommune takes several municipalities at once, so a travel-to-work area is one call rather than six. The aarsresultat filter carries the profitability screening: it keeps only companies whose own newest filed year ran at a profit or a loss, excludes the companies with no filed figures as unknown — never unprofitable — and discloses how many those are in the regnskap_dekning block. rangering is the ordering beside it, and the only route to «de største underskuddene i Norge». It drives from whichever side is selective: inside a scope that fits the candidate ceiling — Ringerike, a narrow næringskode — the accounts of every candidate are read and the order is exact; nationally, or over a scope past the ceiling, it turns the query round and drives it from the accounts register instead — the deepest results in the country first, the company register read only for the ones that survive. No geography is required, and the answer is honest about its edge: rangering_dekning.grunnlag says which side drove, and a window carries its size and the terskel in kroner it was cut at, so the reader can see that this is the top of a ranking rather than a census. Every company in one place, ordered or not, is the same question asked without rangering and with a kommune. stiftet_fra and stiftet_til bound the founding date to the day — «borettslag stiftet siden 2021» is organisasjonsform BRL with stiftet_fra 2021-01-01, nationally, in one count — and every row carries its stiftelsesdato.
What comes back Read dekning before describing any count, because it is the difference between a floor and a market size: only 12.3 % of active AS in a typical catchment carry an employee figure at all, so an employee-filtered answer says nothing about the other 87.7 % and the block states how many those are. A missing antall_ansatte is UNKNOWN and never zero — the register omits the field rather than writing 0, and its own harRegistrertAntallAnsatte flag stands true for 85 359 active AS with no figure behind it, which is why this tool never filters on that flag. The figure that is present is the whole LEGAL ENTITY's payroll and not the address's: Vinmonopolet reads 3 004 employees on one unit standing behind 357 shops, so any question about how many people work at a place needs single_site, which keeps only companies with at most one registered underenhet and, measured over a six-kommune catchment at 200 employees and up, cuts 652 companies to 126. That filter is a fact about the REGISTRATION rather than a site survey — public bodies and security firms under-register their sub-units and pass it — and antall_underenheter is on the row so the claim can be checked. naeringskode_preset: "office_tenant" removes the codes whose staff are deployed somewhere else entirely — bemanning, vakt, renhold and omsorg — because a vikarbyrå with 1 471 employees has a handful of desks; over the same catchment it drops roughly twenty phantom tenants. forretningsadresse is the company's registered seat, which is a company fact and not a property lookup: a firm may operate from somewhere else, and the answer must not present the seat as premises. For a borettslag or a sameie the seat is often the forretningsfører's office («c/o OBOS …»), in another kommune than the building for about a third of the borettslag founded since 2021 — so «borettslag i Oslo» asked by kommune misses them, and the notes say so whenever a geography is set.
About — needs at least one of postnummer · kommune · fylke · naeringskode · naeringskode_preset · organisasjonsform · rangering
mode:"rows" additionally needs a kommune, fylke or postnummer — unless `rangering` orders the answer, which bounds it instead; and `rangering` does not satisfy mode:"count", which orders nothing and still needs one of the indexed selectors
Businesses and premises
Næringseiendommer by their ownership and tenancy profile: one row per matrikkelenhet with the registered owner, a derived profile of that owner (eiendomsselskap, SPV, konsern, portfolio size, legal form), how many businesses stand registered on the property, related-party presence and a local rent estimate.
When to use it The ownership-first way into commercial property. search_commercial_properties starts from what a business DOES and finds its properties; this one starts from who OWNS the property and what stands on it, so «hvem eier næringseiendommene her», «eiendommer eid av SPV-er eller store porteføljer» and «eiendommer der leietakerne er nærstående til eieren» all route here. mode: "count" answers nationally and uncapped — the whole corpus is 72 511 properties — with group_by over kommuner or the twenty biggest owners; mode: "rows" returns the properties, biggest registered floor area first, and requires a kommune or fylke; mode: "dataset" stores the complete set as a file the application renders.
What comes back Three measured traps ride every answer. Tenant counts are ADDRESS REGISTRATIONS, never lease contracts: a business counts as standing on the property because it is registered at one of its addresses, so a kontorhotell or c/o-address reads as hundreds of tenants — one Oslo cluster carries 1 844 — and a high address_org_count on the row is what exposes such clusters. Tinglyst leie is the opposite blind spot, present on ~3 % of the corpus and skewed old, so its absence never means an empty building. The owner profile is DERIVED — er_eiendomsselskap reads the owner's næringskode, er_spv the single-purpose shape, portefolje_antall the owner's properties in this register — screening signals rather than legal facts. And 26 % of the corpus carries no registered næringsareal, so an areal filter is a floor over that blind spot and the unmeasured sort last rather than being dropped. Owners are always juridiske (orgnr) — a private person never appears — and the full grunnbok ownership picture is the get_owners hop each row hands on.
Hands off to get_company_financials get_owners get_property_tenancy
Businesses and premises
The 22 296 parking areas Statens vegvesen holds a registration for, each with its capacity, its charging and accessible spaces, and the operator behind it — resolved through the register of 585 parking providers and on into the company register for that operator's næringskode and size.
When to use it For "how many parking spaces are there here", "who runs the parking in this kommune" and "which car parks have charging points". It is a register of areas, not of ownership: private parking with no registration duty is simply not in it, so an empty answer proves nothing about whether parking exists. mode: "count" answers nationally with group_by over kommune, operator, area type or the operator's næring; mode: "rows" requires a geographic scope or an operator; mode: "dataset" stores the whole scope as a file the application renders.
What comes back Three things decide whether a number from here is right. Over half the corpus — 11 485 of 22 296 rows — is a deactivated registration, so aktiv defaults to true and a deactivated row must never be summed into current capacity. The corpus records NO kommune: every area carries a postnummer, a poststed and a point and nothing else geographic, so a kommune filter is resolved through the postal-code table, an area whose postnummer is not in that table comes back with a null kommune and is counted rather than dropped, and a postnummer straddling a boundary follows the table's assignment. And the operator is often not a company the register knows — operatorer reports the three buckets instead of hiding them: resolved directly as a legal entity, resolved through an underenhet number to its parent ("ONEPARK AS AVD HOVEDKONTOR" is a sub-unit number, not a company), or absent from the company register entirely, which is mostly kommuner deleted in the 2020 reform and wound-up operators rather than a lookup failure. Næringskode 52.212 is not the sector: nationally 69 of the 585 registered operators file it, against 131 filing generell offentlig administrasjon, because most parking in Norway is run by municipalities in-house — so "how many parking operators are there" answered off 52.212 alone misses four fifths of them. Area type decides what a count means: kerbside registrations are 12 181 of the rows and carry a handful of spaces each, so a bare area count is dominated by them while a capacity question is usually about the 8 975 delimited lots and 1 140 structures.
Businesses and premises
One property in, the businesses registered on it out — each with its næringskode and its parent company — together with the party holding the deed and whether the two are the same interest. The single-property inverse of search_commercial_properties.
When to use it An { address } (or { finnkode }) is resolved here and answered from the parcel the property stands on, which is what businesses are registered against — so a borettslagsandel is answerable too. Otherwise it takes matrikkelnummer, up to 25 per call, copied out of a next block rather than typed: resolve_property.next hands the same five-segment keys to get_owners and get_property_facts, and search_commercial_properties.next.get_property_tenancy is the set that search just found. Ask it at parcel level — businesses are registered against the matrikkelenhet, so a seksjon key finds nothing and comes back funnet: false rather than climbing to the parcel by itself. It answers about every registered business, not only retail, which is what "who is in this building" means when the building is the thing being bought. For the grunnbok owner on its own use get_owners; for the buildings use get_property_facts.
What comes back One row per key, matched or not. virksomheter names the businesses registered at the property in Enhetsregisteret — a registration, not a lease: a company can be registered at an address it does not trade from, and a tenant that never registered is not in the list at all. virksomheter_totalt counts every registration on the property, so say how many the named ones stand for. The owner side is the same five roles and the same inferred leieforhold as the set query, read the same way — eierkjede uoppløst is a chain we could not resolve, not a landlord established to be external. overste_eier carries the same typed status as the set query, and only unresolved of its four values is a gap: is_top and no_owner_by_type are answers, with grunnlag naming the ground and evidens the registry field that settled it. On those two the navn is deliberately empty — the top IS the party in spv, so read the name from there rather than showing a blank as an unknown owner — and tied_holders is a count of level-pegged holders, never a list of their names. bra.m2 is every building on the property, which for a shopping centre is the centre rather than the unit. The landlord, its ultimate owner and each occupant's parent company carry their filed accounts under regnskap, read exactly as in search_commercial_properties: a year-by-year array, each entry carrying its own fiscal aar and periode, with egenkapitalandel_prosent as the solvency number and omsetning_kilde separating a filed revenue from an implied zero from an unknown. The occupants themselves do not carry accounts — a sub-unit files none, its parent does.
Reached from get_property_occupants resolve_property search_commercial_properties search_property_holdings
↳ hvem-sitter-i-bygget
About — needs exactly one of unitkeys · address · finnkode
Businesses and premises
The businesses registered at one property, in one cheap indexed hop: name, orgnr, branch-or-company, parent orgnr, and whether the registration belongs to the property's own registered owner or to someone else.
When to use it Reach for it when the question is "hvem er registrert her" and nothing more — it is the light half of get_property_tenancy, which answers the same list and then resolves konsern, eierkjede and regnskap on top. It takes matrikkelnummer, up to 25 per call, copied out of a next block; businesses are registered against the matrikkelenhet, so ask at parcel level. When the follow-up is ownership or accounts, every property row hands its keys onward in next.get_property_tenancy.
What comes back One row per key. Each registration carries relationship: owner_occupier is registered at the property AND matched to its registered owner; presumed_tenant is registered there and NOT the owner — which suggests a tenancy and does not establish one. A registration is an Enhetsregisteret address, not a lease: a company can be registered where it does not trade, and a tenant that never registered is missing entirely. confidence scores the address match; rows under 0.8 are flagged in the notes and must be qualified. Totals count every registration even when only the first 100 are named. Ask with mode: "dataset" when the answer is a LIST the reader will act on — and always when a rows answer came back truncated. That stores every registration as a dataset the app renders directly and the CSV carries whole, instead of naming the first 100 and leaving the rest to be retyped: Storo Storsenter registers 153, and a capped list is where a table stops matching its own count. The dataset answer is a small envelope — columns, counts, a five-row preview and merknader — and the rows are read from the stored file, never from the preview.
Hands off to get_property_tenancy
Businesses and premises
The tinglyste leieforhold on a property — leases someone paid to register in the grunnbok — with tenants, the nominal yearly rent of the tinglysing year, area and kr/m² where recorded, and the registered text lines.
When to use it For "finnes det tinglyste leiekontrakter her" and for reading what an old registered lease actually said. It takes matrikkelnummer, up to 25 per call, copied out of a next block. It is NOT the rental picture of the property today: most modern leases are never tinglyst, so use it as a record of what was registered, alongside get_property_occupants for who is registered at the address now.
What comes back Standing leases first, then historic, newest tinglysing first. aarlig_leie is the NOMINAL figure of the tinglysing year — a 1963 lease is in 1963-kroner and must never be presented as current rent; the tinglyst year travels beside it for exactly that reason. leie_kilde: "fritekst" means the figure was parsed out of the registered text lines, which are included verbatim in tekster — quote them when precision matters. An empty answer proves nothing about whether the property is let; say "no registered leases", never "no leases". The corpus skews old, with most registrations from the 1980s–90s.
Market statistics
Sold homes and the homes on the market today — as aggregate statistics, or as the individual records behind them. Plus the commercial side of the same question: what næringslokaler ask in rent, and what næring, fritid and tomt ask in price. Every figure in this group is ASKED rather than achieved, and every one carries the coverage it was computed over.
Market statistics
Aggregate statistics over verified sold homes: counts, averages and medians, kr/m², sold-vs-asking and days on market — by municipality, county or bydel, over a window of up to 12 months — up to 60 with a municipality or a bydel.
When to use it For the trend line. For the individual homes behind the numbers — a table, a top-20, links — use search_sold_homes. It narrows on the same row filters as search_sold_homes — build year, price, kr/m², size, rooms, bedrooms, energy label, the features, how far over asking a home went and how long it lay out — so «hvor mange leiligheter bygget etter 2010 gikk over prisantydning» is one aggregate call rather than pages of sales counted by hand. Set agency with groupBy: "agent" to rank meglere within an office, or groupBy: "agency" to rank the offices — in a kommune, a fylke or nationally. Below the kommune the offices are ranked too: groupBy: "agency" with a bydel_navn, a delbydel, grunnkrets or delområde, or a radius — and no agency/agent — answers «hvilke meglerkontorer har solgt flest på Grünerløkka» in one call, counted from the verified sales rather than the agent↔listing index, which is kommune-level. That ranking takes the row filters and carries the price metrics per office; a per-agent ranking cannot follow it, because the register names the office and never the megler. Several periods at once: windows answers up to twelve of them in ONE call, each with its own period and its own row-filter override, so a year-by-year series with a rolling build year is one call rather than eleven — and eleven is most of the tool budget for a single turn. A window that names a period replaces the call-level one; everything else stays as set at call level, which is what makes the windows comparable, and a window that tries to move the geography or the grouping is refused rather than obeyed. The reply carries windows, one figure-bearing line per window in the order asked for, and results, the full envelope for each window at the same indexes. exclude_registry_dated: true leaves out the sales known only from tinglysing — ads withdrawn and sold later without a new one — whose sale date is the day the sale was registered. Add same_agencies: true to compare the windows on the same brokers: every window then counts only the offices with a sale in every window, and the same_agencies block says how many offices that is and how many of each window's sales it kept — «september mot samme måned i fjor» without an office that started or stopped reporting in between. Asking-price cuts are price_changes: true: every bucket then carries how many homes sold below their first asking price, the median cut, the cuts and raises, and coverage_share — the share of homes whose price history is complete, which it is from autumn 2024. Each sale reads its own ad, so one call covers at most 25 000 sales; a wider question is refused with the scopes that fit, never answered in part. A low count over a period with low coverage_share is a gap in the record, never a finding that prices were not changed.
What comes back Aggregates only — never a raw row or an address. groupBy: "month" is the shape a chart wants; none gives one summary. format: "data" returns the numbers alone; format: "deck", the default, appends a short instruction asking the assistant to render them as a self-contained HTML presentation. The two prices — kr/m² and the sale price incl. fellesgjeld — carry a median beside the average: the middle sale, or with an even count the lower of the two middle ones. data_quality counts, per metric, the provably impossible values excluded from its average, while num_sales still counts every transaction in the bucket. A row filter beside an agency/agent ranking is refused rather than dropped: that leaderboard is counted from the agent↔listing index, which holds no build year, price or size. An office ranking below the kommune is a different population — verified sales, which name the office on 99.5 % of rows — and says so: agency_coverage counts the sales with and without an office, «(ukjent)» is the bucket without one, and the legend states that a sale enters this register when it is registered, so the newest weeks undercount against the ad-counted kommune-level ranking; the two are compared by definition, never by total. A month series carries the figures a reader would otherwise total up by hand: the average per month, the quietest month and the busiest one, each with its month, sit in overall alongside the number of month buckets the average divides by. That divisor is returned because it is the part that surprises — in groupBy "month" a month with no rows produces no bucket and is not in it, while "active_month" returns every month the window touches, zeros included.
↳ markedstall · ↳ ukjent-bydel
Narrowing — needs at least one of lastMonths · from · windows · agency
Market statistics
The same engine pointed at the active for-sale inventory: how much is on the market, at what asking price per m², how long it has been listed.
When to use it The supply-side counterpart to summarize_sold_homes — put the two next to each other to compare what is being asked with what is being paid. It narrows on the same row filters as search_homes_for_sale — build year, price, kr/m², size, rooms, bedrooms, energy label, days on market and kitchen/bathroom standard rating (0–10, photo-derived, higher = newer/better-maintained; «oppussingsobjekt»/«trenger oppussing» ≈ max 3, «nytt kjøkken»/«nytt bad» ≈ min 7; unrated listings are excluded rather than matched) — so «hvor mange boliger bygget 2021–2026 ligger ute» is one aggregate call rather than pages of listings counted by hand. It offers two month series, and they are not the same curve: groupBy "month" counts the ads ADDED that month among the homes still for sale, so it decays going backwards in time as older ads leave the book, while groupBy "active_month" counts the STOCK — every home that was on the market during the month, the ones since sold or withdrawn included — which is what «lå ute», «har ligget for salg», «var til salgs» and beholdning actually mean. A listing has a third end besides selling and still being out there, and outcome:"withdrawn" is it: the homes TAKEN OFF the market without a sale — «trukket fra markedet», «trukket», «avpublisert», «tatt av markedet», «ikke solgt, fjernet», «inaktive annonser». A sold home is never one of them. That mode answers the count and the share in the same call, because 261 withdrawals in Oslo in June is not a fact anybody can use without knowing 261 out of what. And outcome:"all" is the split — every home on the market in the period, counted by how it left: sold, withdrawn, or still for sale at the end — which is «andel solgt vs trukket» and «hva skjedde med boligene som lå ute i juni». Several periods at once: windows answers up to twelve of them in ONE call, each with its own period and its own row-filter override, so a year-by-year series with a rolling build year is one call rather than eleven — and eleven is most of the tool budget for a single turn. A window that names a period replaces the call-level one; everything else stays as set at call level, which is what makes the windows comparable, and a window that tries to move the geography or the grouping is refused rather than obeyed. The reply carries windows, one figure-bearing line per window in the order asked for, and results, the full envelope for each window at the same indexes. Asking-price cuts are price_changes: true, on the active book and on outcome: "withdrawn" — «ble de satt ned før de ble trukket?» — with the same coverage_share as on the sold side. A low count over a period with low coverage_share is a gap in the record, never a finding that prices were not changed.
What comes back Resale homes (bruktbolig) only; new-builds are not in the corpus. The AVM estimate and the asking-vs-estimate ratio are part of a separate add-on — see what a key reaches, below. A row filter beside an agency/agent ranking is refused rather than dropped: that leaderboard is counted from the agent↔listing index, which holds no build year, price or size. The stock series returns num_listings alone, covers whole calendar months, defaults to the last twelve, and counts homes first advertised up to 24 months before the window; its monthly figures overlap — a home on the market from March to June is in all four — so they are never summed, and the overall figure counts each home once. It takes no agency/agent ranking and no days-on-market bound, because neither can say anything about a past month. A month series carries the figures a reader would otherwise total up by hand: the average per month, the quietest month and the busiest one, each with its month, sit in overall alongside the number of month buckets the average divides by. That divisor is returned because it is the part that surprises — in groupBy "month" a month with no rows produces no bucket and is not in it, while "active_month" returns every month the window touches, zeros included. A withdrawal answer carries three figures per bucket rather than one — how many were pulled, the stock they were pulled out of, and the share those two make — and the stock behind that share is clipped to the period rather than rounded out to whole calendar months, so a period starting mid-month never divides a few days of withdrawals by a whole month of inventory. Its one approximation is the same 24-month look-back the stock series carries: a home first advertised longer ago than that and withdrawn inside the period is counted as withdrawn but is not in the denominator, which on the live book is around one withdrawal in a hundred. The count stays exact, because the count is the answer. The split is a counting mode — counts and shares of the stock, no price metrics — and every figure in a bucket is read off the same homes in one pass, so the three counts sum to the stock and the three shares to one. Its withdrawn count is taken inside that look-back rather than off the withdrawn index, so it can differ from outcome "withdrawn" by a handful for the same period; the legend says so and in which directions. It carries none of the month figures — three overlapping stocks have no one figure to average — and every answer carries the definitions in one line each: SOLD = the broker marked the ad sold (sold: true) — the brokered sale, weeks before it is tinglyst; counted when the home left the market, normally sold_date. WITHDRAWN = taken off the market with no sale recorded (inactive: true, sold null), dated by inactive_date. STILL ON MARKET = on the market in the period and neither sold nor withdrawn by the end of it.
↳ trukket-fra-markedet
Market statistics
The individual sold records behind the statistics — one row per home, each with its new_unitkey, a Finn URL, a Solgt URL, sold and asking price, area and dates.
When to use it For tables, top-N lists and drill-downs. A sold_date window is required: up to 12 months, or up to 60 with a municipality or a bydel; a page holds 25 rows by default and 1000 at most, and each row counts against the document quota. A street is a geography of its own: street with a kommune answers «hva er solgt i Thereses gate det siste året» with the homes whose registered address is on that street — every house number, matched against the register's own address string with the usual abbreviations resolved — and never with a radius around one of them. It takes the street NAME; a house number on it is refused and the name to send is given back, because one address is resolve_property's question.
What comes back Sortable on computed fields — over_asking_pct and days_on_market — so "the 20 homes that went furthest over asking" is one call, not a client-side sort of everything. A street-scoped answer carries a street block naming the street, the spellings it matched and the kommune, and an empty one says whether the street exists at all: not_found on street means no home was ever listed under that name in the kommune, while empty means the street is real and the window quiet. mode:"dataset" answers the whole result set at once: the rows are stored as a file the calling application renders itself and the call returns a small envelope — columns, row count, a five-row preview and the caveats — so a list longer than a page never has to be paged, and never passes through the model that would retype it. Every row carries lat/lng, in the dataset as on a page, so the set can be drawn on a map.
Narrowing — needs at least one of lastMonths · from
Market statistics
The individual active listings: asking price, total price including omkostninger, days on market, area and agency, each with a Finn and a Solgt URL.
When to use it A narrowing filter is required — geography, a date window, or a price/size bound — because the inventory is not a browsable catalogue. It takes the same row filters as summarize_homes_for_sale, including kitchen/bathroom standard rating (0–10, photo-derived, higher = newer/better-maintained; «oppussingsobjekt»/«trenger oppussing» ≈ max 3, «nytt kjøkken»/«nytt bad» ≈ min 7; unrated listings are excluded rather than matched). A page holds 25 rows by default and 1000 at most. street with a municipality lists the homes for sale on one street — the register's own address string, every house number, never a radius — and takes the street NAME alone. outcome:"withdrawn" points the same rows at the homes that were TAKEN OFF the market without a sale, which is the drill-down behind a withdrawal count.
What comes back utlegg crosses THIS PAGE of listings with grunnbokens tvangsforretninger (utleggsforretning, utpanting): "annotate" marks every row, "only" keeps the ones that carry one. It reads at most 50 listings and total still counts every listing the filters matched, so the marked rows are this page's and never the complete set of encumbered homes in an area — a count of them is not a market figure. It is NOT tvangssalg, which no register this surface reads holds as a heftelse, and it needs the encumbrances add-on. A row coming back utlegg: null was not looked up at all, which is silence rather than a zero. mode:"dataset" answers the whole result set at once: the rows are stored as a file the calling application renders itself and the call returns a small envelope — columns, row count, a five-row preview and the caveats. Ask for it instead of paging. Every row carries lat/lng, in the dataset as on a page, so the set can be drawn on a map. A COUNT is a different question and belongs in summarize_homes_for_sale, which takes the same row filters. A withdrawn row carries withdrawn_date, and its days_on_market is the time it actually lay out — listed until pulled, not until today — so min_days/max_days and sorting by it select on exactly that. An agency/agent filter is refused in that mode rather than dropped: the agent↔listing index behind it records who is selling what today and holds no withdrawn ad. min_price_changes and the price_changes_count column count the entries in the ad's own price history, so a withdrawn ad from before 2026 counts too.
About — needs at least one of county_name · county_number · municipality_name · municipality_number · bydelsnavn · grunnkretsnavn · delomradesnavn · delbydelsnavn · fylke_name · fylke_number · kommune_name · kommune_number · bydel_navn · grunnkrets_name · delomrade_navn · delbydel_navn · lat + lng + radius_km
Narrowing — needs at least one of lastMonths · from · agency · agent · min_price · max_price · min_sqm_price · max_sqm_price · min_sqm · max_sqm · min_rooms · max_rooms · min_bedrooms · max_bedrooms
Market statistics
Drill-down by new_unitkey: for up to 25 keys, the latest sold record and the active for-sale record for each, merged into one entry per key.
When to use it new_unitkey is the stable id that leads every row from the search tools, so this is how you fetch full detail for the homes an earlier search surfaced.
Market statistics
Median, p25 and p75 asking rent for næringslokaler in kr/m²/år, over a geography you name — the first tool on this surface that answers with a derived number rather than with rows. It returns no properties and no listings.
When to use it For "hva er leieprisen for kontor i Oslo", "hva koster lager i Fredrikstad" and "har leieprisene steget siden 2020". search_commercial_properties answers with the PROPERTIES a business operates from and search_homes_for_sale with bolig listings; this one answers with the market's numbers. A geographic scope is required — kommune, fylke or postnummer — because a national median over this corpus would mix Oslo kontor with kerbside parking in Finnmark and read as a market it does not describe. property_type is membership rather than equality, since an advert carries several kinds of use at once, and the values are single tokens: "Butikk/Handel" is ONE of them, so splitting it on the slash matches nothing at all. mode:"count" returns the statistics with group_by over year, kommune or property type; mode:"rows" returns the priced adverts behind them so a median can be checked against the ads it came from; mode:"dataset" runs the whole scope and stores it as a file the calling application renders. Several periods at once: windows answers up to twelve of them in ONE call, in mode:"count" only, each with its own years and its own property_type, so a year-by-year comparison is one call rather than a dozen. The geography stays as set at call level, which is what makes the windows comparable; compare_with and windows are refused together, because each multiplies the queries and together they multiply each other.
What comes back unit is on every response and must be read off it rather than assumed — it is the one field that decides whether the answer is right. Bolig-leie is quoted in kr/MÅNED and næringsleie in kr/m²/ÅR, the same underlying field name roughly twelvefold apart. The source itself carries two units under that one name: some meglere enter a total årsleie and others enter kr/m²/år, and the answer states how many rows had to be divided by their area to reach a common scale. Every figure is ASKING rent and never contracted rent — what a tenant actually signed is in no register we hold, and the gap between the two is real. Read coverage before describing any median: only about 5.7 % of kontor adverts carry a price at all, so the number is a fact about the priced fraction and never a description of the whole market, and the block states how many adverts sit on the other side of that. A group with fewer than 15 priced adverts keeps its median and gains tynt_grunnlag: true — report it WITH its n and the flag rather than presenting it as solid or withholding it, because the thin number is still the only one the corpus holds. What must never happen is fixing a thin sample by dropping the type filter: pooling kinds of premises multiplies the sample and produces a figure that describes no market anyone can rent in. Measured over Oslo, Butikk/Handel runs at 2 375 kr/m²/år and Lager/Logistikk at 1 100 — 2.2× apart — and all types pooled gives 1 500 over 884 adverts, which is right for neither. The supported move is the opposite one, and compare_with is the only widening the tool offers: it moves the GEOGRAPHY while holding the property type and the year range fixed, returns the requested scope completely unchanged, and adds the wider figure as a separate block carrying its own note saying it is different geography. Ås kontor stays at n=7 with Nordre Follo kontor beside it, and the wider block must never be presented as the answer to the narrower question. rows_excluded_sanity counts adverts whose stated price was impossible, such as the one stating 12 001 500 kroner on 30 m²; they are dropped from the median and counted in the open, because a filter nobody is told about is a lie. Geography resolves through the postal-code table, so a postnummer straddling a kommune boundary follows that table's assignment.
About — needs at least one of kommune · fylke · postnummer
Market statistics
Median, p25 and p75 PRISANTYDNING for commercial premises, holiday property and bare land — in kroner, or per square metre with the area basis named. The sale-side twin of get_commercial_rent_stats, over the same engine.
When to use it For "hva koster næringslokaler i Oslo", "kvadratmeterpris for kontor i Bergen", "hyttepriser i Trysil" and "tomtepriser i Ås". It is NOT a record of what anything sold for: search_sold_homes and get_comparable_sales carry ACHIEVED prices from the register, and these are ADVERTISED asking prices, which is a different number and must never be presented as the other. vertical picks one of three separate corpora — business_sales, leisure_sale or plots — deliberately not pooled, because their per-m² figures are not comparable: a hytte's floor metre and a tomt's land metre differ by more than an order of magnitude, so an average across them describes nothing. A geographic scope is required, and property_type is validated against the CHOSEN vertical's own vocabulary, so a type that corpus does not use is refused by name instead of returning a confident zero. Several periods at once: windows answers up to twelve of them in ONE call, in mode:"count" only, each with its own years and its own property_type, so a year-by-year comparison is one call rather than a dozen. The geography stays as set at call level, which is what makes the windows comparable; compare_with and windows are refused together, because each multiplies the queries and together they multiply each other.
What comes back unit names the area basis, and that is the point of it: kr is the asking price, kr/m2_gulv divides by FLOOR area and kr/m2_tomt by PLOT area. Both of the latter are "kr/m²" in ordinary speech, which is exactly why the response spells out which one it is — a tomt at 1 500 kr/m² is ordinary and a floor at 1 500 kr/m² is a data-entry error. The plots corpus records no floor area at all, so it always uses the plot and refuses a floor basis rather than answering emptily. These corpora are far better priced than the rental one — about 81 % of commercial sale adverts and 99 % of leisure adverts carry a price — but coverage still decides how a number may be described, and rows_excluded_no_area is what matters for a per-m² answer, because roughly a third of commercial sale adverts state no area at all and drop out of it entirely. A group under 15 priced adverts keeps its median and gains tynt_grunnlag: true, and the way to strengthen it is compare_with — a wider GEOGRAPHY with the vertical, type, metric and years all held fixed, added as a labelled block beside the requested scope rather than replacing it. Never grow the sample by pooling property types or by switching vertical: that buys a bigger number describing none of the things it was averaged over. rows_excluded_sanity counts impossible figures dropped from the median: the bottom of every one of these verticals contains placeholder prices of a single krone.
About — needs at least one of kommune · fylke · postnummer
Market statistics
Median, quartiles and kr/m² per month of ASKING RENT for homes, from rental adverts, over a kommune, a bydel, a fylke or a set of postal codes — with the number of ads behind every figure.
When to use it For «hva er realistisk leie for en 2-roms på Grünerløkka», «hva koster det å leie enebolig i Bærum», «har leieprisene i Bergen steget» and «hva kan jeg ta i leie». It is the residential twin of get_commercial_rent_stats and answers in kr per MONTH where that one answers in kr/m² per YEAR; unit is on every response so the two are never confused. The corpus records SOVEROM, not rooms: a «1-roms» is a studio with 0 bedrooms on most ads and 1 on some, so it is asked as max_bedrooms: 1 with a size band, and a «2-roms» is one bedroom. A geographic scope is required; a bydel resolves to the postal codes whose verified sales mostly lie in it, and the codes that straddle a border are named. The window is the advert's publication date, twelve months by default and two years at most. Without a property_type the answer covers whole dwellings and hybler and says so; a room in a shared flat, a garage or a cabin is counted only when named. mode:"rows" returns the adverts behind the numbers, newest first, and mode:"dataset" stores the whole set as a file.
What comes back Asking rent, never contracted rent, and the caveats say so in Norwegian on every answer. overall and each group carry n, the n the median actually rests on, median, p25/p75, p10/p90, mean, min, max and a kr_per_m2_mnd block with its own n — the ads that also state an area (P-rom, else BRA-i). coverage separates the ads in scope from the ones priced, the placeholder prices dropped (the corpus holds ads asking 1 kr) and the share with an area. A group under fifteen ads keeps its figures and gains tynt_grunnlag: true; the honest repair is a wider geography or window with the type and bedrooms held fixed, never a pooled sample. Percentiles are computed in the database (t-digest), measured against the exact interpolation to within a rounding step.
About — needs at least one of kommune · fylke · postnummer
Market statistics
One Finn ad, whole: the seller's presentation as it ran — title, prices with omkostninger and fellesgjeld, the monthly and yearly costs, key facts, every image with its megler caption, viewings, price history, the ad's own matrikkel keys and, for a borettslagsandel, the andel's own key.
When to use it For "hva sto i annonsen" and everything the ad itself can answer — including "finnes det bilder av badet", which the image captions answer, and "hva er fellesgjelden" or "hva dekker felleskostnadene", which the price block answers. It takes a finnkode from a search row or a finn.no URL. Homes (the sold archive included), lettings, business_sales, business_lettings, leisure_sale and plots answer, and the payload names which one held the ad; nybygg project ads do not. The prose is windowed by section — every heading is always listed, contents eight sections per call, next carries the rest — so read on before claiming the ad is silent on something.
What comes back The ad is MARKETING: the selling side's presentation, megler captions included. Present its claims as the listing's claims — the registered facts live in get_property_facts, get_owners and get_conveyances, and matrikkel hands over the full five-segment keys to check with. On a borettslagsandel those keys are the borettslag's parcel; housing_cooperative names the borettslag with its orgnr, and housing_cooperative.unitkey is the andel's own key, which those tools answer for that one home. price.total is the totalpris: prisantydning + fellesgjeld (price.collective_debt) + omkostninger, so the fellesgjeld is already in it. price also carries the andel's fellesformue, the monthly felleskostnader with what they cover in the megler's words, and the yearly kommunale avgifter where the ad states them; a figure the ad does not state is null, never zero. facts.bra is the BRA the ad states. Ads from 2024 on split it into facts.bra_i and facts.bra_e. Older ads carry facts.p_rom instead, and their bra_i is null, because the old BRA includes the boder. When an archived salgsoppgave exists for the ad, next.get_salgsoppgave says so; sold/inactive status and dates come from the archive row, not the ad text.
Hands off to get_salgsoppgave
Market statistics
The listing's own documents read as text — the salgsoppgave with the takstmann's tilstandsrapport and the verditakst inside it, which is where the TG-graderinger live — plus TG2/TG3/TGIU counts and the takstmann's kostnadsanslag in kroner, both parsed from that text.
When to use it For "les salgsoppgaven" and every TG question: TG2/TG3 findings, «hva må utbedres», what the tilstandsrapport says about a specific room, the estimated cost bands. It is also where a TAKST is answered from — «hva er taksten», «verditakst», «hva satte takstmannen» ask for the takstmann's own signed figure for that home, which is in this document; Solgt.no's model estimate over comparable sales is the other question, and that one is get_avm. It takes a finnkode. A full prospekt runs to 50+ pages, so the text arrives windowed — offset/length, 20 000 characters by default, with next carrying the following window. Coverage is partial: ~190 000 archived prospekter against 1.76 million ads, so an empty answer is a statement about our archive, never that no salgsoppgave existed.
What comes back The SELLER'S document, not a register — megler marketing plus the report the selling side paid for. Present its claims as the prospekt's claims and check the facts against get_property_facts, get_owners and get_conveyances. summary carries the TG2/TG3/TGIU counts parsed from the text by a parser scored against hand-counted prospekter — exact or null, never a guess: a null summary means the format could not be read, not that the home has zero findings. method says how it was read: index counted the report's own index and carries the component list, while count_block and stated_count read a tally the report printed for itself and carry no components at all — so an empty component list beside non-zero counts is the whole answer rather than a truncated one. summary.costs is the takstmann's own kostnadsanslag from the same text, in kroner — a band per finding it could attribute and their sum. It is the takstrapport's estimate, not ours, and it is usually incomplete: NS3600 only requires a price on TG3, so partial: true is the norm and the total then covers priced_findings of total_findings, never the whole repair bill. tilstandsgrader is the tilstandsrapport's per-finding grid — one row per finding with the bygningsdel, the takstmann's own wording and his cost band where he priced it — which a client that shows the findings renders from the payload. The wording per row is the takstmann's; the grade a row sits under and the per-grade counts measured unreliable, so the totals come from summary and the rows from tilstandsgrader. archived_at dates the capture — the archive is a point-in-time copy, so the text, summary and tilstandsgrader all describe the edition archived that day rather than whatever the meglerhus serves now (measured: 1 of 20 sampled prospekter had been revised since). pdf_available states whether the archive holds the PDF. It is an existence claim, not a link — the meglerhus's own address is deliberately not carried, because a quarter of those links are dead and a live one returns the same document the archive already holds.
Reached from get_listing_full