Placepoint API guide
The Placepoint API is a REST API for property, company and area data in Norway and Sweden: matrikkelnummer and fastighetsbeteckning lookups, owners, tenants, transactions, building permits, valuations, zoning and more, plus webhooks for change events. It uses OAuth2 client credentials, JSON bodies, cursor pagination and RFC 9457 error responses throughout.
Base URL and contact
The API is served from https://data.placepoint.no; api.placepoint.no becomes the host once the PropCloud APIs behind it are shut down.
Contact: support@placepoint.no.
This guide covers the parts that apply across the whole API. For request and response shapes, parameters and examples on a specific operation, use the operation pages listed under Every operation.
In this guide
- Quickstart: a token, a property lookup, tenants, and a webhook subscription in under 10 minutes.
- Authentication: the client-credentials grant, scopes, and getting a trial key.
- Identifiers: matrikkelnummer, fastighetsbeteckning, organization schemes and address encoding.
- Pagination and filtering:
pageSize,pageToken, and which operations page. - Errors: the Problem Details body and the response types the spec uses.
- Webhooks: CloudEvents payloads, signature verification, subscriptions.
- Rate limits and quotas: rate-limit headers, the daily call cap, idempotency.
- Sandbox: the demo properties a trial key can reach, until there is a separate sandbox host.
- API lifecycle: what may change without notice, what counts as breaking, and the deprecation and sunset timeline.
- Changelog: every change to the contract, newest first, with the version it shipped in.
Every operation
Generated from the spec; each row links its reference page for parameters, fields and examples.
Some fields on owners, buyers and sellers are personal data and require the owners.read scope on top of the scope for the operation itself; without it, the field is omitted.
What may change without a new major version
The contract grows. Write clients that tolerate growth, and a new field or a new classification value never breaks them:
- New response fields appear. Ignore what you don't read; don't reject a response because it carries a property you don't know.
- Classification values grow.
Document.kind,Certification.schemeand the webhook event types are markedx-extensible-enumin the spec: the documented values are the ones we serve today, and more follow as new registers and schemes are connected. Map an unknown value to your own fallback rather than failing the parse. - Request enums stay closed. A value we accept today keeps working; that is the half of the contract you can hard-code against.
What will not happen inside a major version: a field removed or renamed, a
type changed, a required request parameter added, or an endpoint withdrawn.
info.version in the spec is semver, and every change is listed in the
release notes.