About these help pages

These help pages are Placepoint's official user documentation, a single reference to look things up in while you work. Large parts are generated automatically from Placepoint Fusion and from the sources we collect data from. Here we explain how the pages are made, and how you can tell us if something is wrong.

How these pages are built

The pages are built with Docusaurus from Markdown files maintained by the Placepoint team. Every change rebuilds everything and publishes it to docs.placepoint.no. There is no full-time editorial team, so updates happen continuously, much of it automatically.

Most of the work is done by scripts and AI agents that use Placepoint the way you do. Below are the parts, and what is automatic in each of them.

Screenshots

The help pages run to more than 3,500 pages with more than 2,900 screenshots. That count includes the translated pages and the screenshots retaken in each language, because they are separate pages and separate images. The images are taken by Playwright: a script logs in to Placepoint Fusion, navigates through all the panels and takes an image of each of them. If a screen changes in the product, the tour runs again and the affected images are replaced. All the images are captured in dark theme and at the same window size, so the pages look the same from top to bottom.

Videos

14 short videos show the most common actions, collected on Videos. They are recorded the same way as the screenshots: the script performs the action in the app and films the screen while it happens. No voiceover and no post-editing. Each video also sits on the page that documents the feature it shows.

The numbers

Numbers about the platform, such as the count of matrikkelenheter and companies, are collected on Placepoint in numbers. Every number is measured against the databases behind Placepoint and given rounded, because an exact number is out of date the moment it is published. Each number comes from one place, and an automatic check refuses to publish a page that states a number we have replaced.

Translations

The pages exist in Norwegian, Nynorsk, Swedish and English. The translations are made automatically from the Norwegian text, which is the only version written and read through by people. A check compares each translated page with the Norwegian source, and publishing stops if a translation is missing or has been left behind after a change. If you find something that jars in a translation, the Norwegian page is the authority.

Search

The search field at the top of every page indexes the whole documentation, including the Glossary, Data and sources and the FAQ. Search for feature names ("map layer", "matching"), technical terms ("UFA", "matrikkel") or whole questions. This is often the fastest route if you know what you are looking for, but not where it is described. The search tolerates typing errors, and it knows more than 600 synonyms in four languages. Many of them are taken from the pages themselves, so a search for the word you use finds the page that uses another.

The Glossary

The Glossary is written here and mirrored from here to placepoint.no, together with the screenshot that belongs to the term. The image is published from the help pages and linked onwards, so it exists in one version and cannot disagree with itself. A term with no surface in Placepoint to point to gets no illustration, rather than an image that does not match the text.

News

When a new version of Placepoint is out with customers, a draft news article about what is new is written automatically. The draft is read through by one of us before it is published, so nothing goes out unseen.

Placepoint API

Placepoint API is the REST API that gives a system the same data that Placepoint Fusion gives a person. It has two sets of pages, and both are made from the same source: the product pages under /api/ in Norwegian, one per endpoint, and the technical reference for developers in English, at docs.placepoint.no/developer.

The source is the API contract, an OpenAPI description of each endpoint: which parameters it takes, which fields it responds with, what each field means and an example response. The field lists, the curl examples and the example responses on the pages are not written by hand, but built from the contract every time the pages are published. The technical reference is generated from the same file. A page therefore cannot disagree with the API it describes: if we correct a field in the contract, both sets change in the same round.

The checks around this are stricter than for the rest of the documentation, because people build integrations on what it says. The contract is checked against our own API rules, each endpoint must sit on exactly one product page, the product page and the reference must link to each other, and a change that would break an integration that works today stops publishing. What can change without notice, and how long you have when something is to be removed, is on API lifecycle; every change in the contract is listed in Changelog.

The endpoints respond once the API has launched. The Tenant API already responds, with a trial key you fetch yourself.

The pages check themselves

Before a change is published, fourteen automatic checks run across the whole documentation. Among other things, they refuse a page that links to a page that does not exist, a page nobody reaches from the menu, a number we have replaced, a translation that has been left behind, and a screenshot taken while the map was still loading. A separate image check looks for blank maps and half-loaded screens, which is the most common error when the images are taken by a script.

The pages are also prepared for AI tools: llms.txt describes the content in a format language models can read, so a question put to an AI assistant can be answered with what actually stands here.

A longer walkthrough of how the parts fit together is in the article How docs.placepoint.no works. It describes the system as it was when it was written, and becomes less accurate as we rebuild.

Where the information comes from

The content is stitched together from several sources: feature descriptions and examples are written by the team based on the running app; the FAQ is a curated collection of questions we are often asked; short how-to answers behind the green i icon at the bottom right in Placepoint cover the same features; the Glossary explains more than 300 terms from property, planning and construction, enriched with links to Lovdata, Kartverket and other authoritative sources; Data and sources gives you the opposite entry point, listing the datasets Placepoint combines, who supplies them and where you can find them directly at the source. When a source is updated, we fetch it again and rebuild the pages.

What might be wrong

Most of these pages are made by AI agents that actually use Placepoint Fusion: they log in, click through the app, take screenshots along the way and learn the features bit by bit, with a little help from us. That means the documentation rarely lags behind the product, but also that some kinds of errors can slip in:

• Screenshots taken at a slightly odd place on the map compared with what they are meant to show.
• Screenshots that have failed, for example where a map layer did not finish loading before the image was taken.
• Text that is slightly off the mark and needs a human polish.
• Terms or fields imported from external sources with small errors that have not been caught yet.
• Links that point to a page a data source has moved.

Tell us when you spot something. We are very happy to receive feedback. Every message helps us pick up genuine errors quickly and prioritise correctly what the next round should improve.

Help us improve

Feedback is the fastest way these pages get better. We would particularly like to hear what is missing or should be better documented: tell us if you are looking for something and cannot find it, if an example would have made a feature easier to understand, or if you have a workflow we have not covered. We are happy to receive requests for both basic examples ("how do I find the owner of a property?") and advanced ones ("how do I combine matching, monitoring and demographic search into a portfolio candidate pipeline?"). Good examples are one of the most requested things we have.

Three channels for feedback, from the shortest to the most detailed:

• "Did you find what you were looking for?", the button at the bottom of every single help page. One click is enough; a comment with it is gold. We read every single piece of feedback and use it actively to prioritise what to improve in the next round.
• The chat bubble at the bottom right goes straight to the Placepoint team. Use it for short observations. Staffed during working hours.
• Email to support@placepoint.no is good when you want to write a bit more or attach screenshots.

If you mention the URL of the page in question, we will find it quickly.

Placepoint v1, Placepoint Maps (Newsec Maps) and PropCloud

We also have user documentation for three other Placepoint surfaces:

• Placepoint v1, the predecessor to Placepoint Fusion, still running at console.placepoint.no.
• PropCloud, search in properties, companies and ownership, area analysis and project folders at app.propcloud.no.
• Placepoint Maps, maps, property data and analysis tools at app.newsecmaps.com.

Feedback and requests about these three sets are received in the same way as here: the chat bubble or support@placepoint.no.

Experiments

We have made a few small data-driven experiments, more or less finished. Placepoint AI makes Placepoint's data and functionality available in Claude, and the Agent does the same inside Placepoint Fusion.