Data Model

/v1/ covers six data domains plus pre-computed property KPIs, listed by table below. Field-level detail lives in the API reference for each endpoint.

Accounting

accounts, booking_headers, booking_positions, budgets, and account_hierarchies

Contracts

service_contracts, contract_debits, contract_debit_diffs, contract_ends, and index_rent

Depreciation

assets and depreciation

KPI (Preview)

property_kpis and property_kpis_by_floor_area_type, aggregated from the other domains

Operations

notifications, offers, orders, projects, and requests

Property

properties, property_structure, property_creditor_services, and technical_objects

Stakeholder

creditors, employees, owners, and tenants

How the tables connect

property_id is the join key shared across every table on this page. A booking transaction produces one booking_headers row, which groups every line item it posts (booking_positions). Line items post to accounts of different types — general ledger, tenant, creditor, project, or cost centre, see accounts.account_type_name. A transaction usually involves one creditor, tenant, or cost centre, so booking_headers already contains creditor_id, person_id, and property_structure_account_id itself — no join through booking_positions needed.
Each account can have a budget for a given month. For a cost centre, property_structure.account_id matches the accounts.account_number of the corresponding accounts row — not its accounts.account_id. contract_debits references the general ledger account it posts to via account_number, matching accounts.account_number. contract_debit_diffs uses the same account_number field name, but resolves to a tenant account instead — same column name, different account type per table. contract_debits.debit_type.code is a different thing, a debit-type code, not a ledger reference (see the account_id row below).

Join keys in detail

Key	Meaning	Cardinality
`property_id`	Identifies a property. Present on every table on this page except `creditors` (a standalone entity, referenced via `creditor_id` instead).	1 property → many rows in each domain
`booking_header_id`	Groups booking line items under one header.	1 `booking_headers` → many `booking_positions`
`account_id`	Internal account identifier on `accounts`, `booking_positions`, `budgets`, and `account_hierarchies` — joins across those four. `index_rent.account_id` and `contract_debits.debit_type.code` mean something unrelated: a debit-type code — don’t join those to `accounts`. On `property_structure`, it means something else again: a cost-centre business code, matching `accounts.account_number` for the corresponding cost-centre row, not `accounts.account_id`.	1 `accounts` row → many `booking_positions`/`budgets` rows, one `account_hierarchies` row per reporting structure
`account_number` (on `contract_debits`/`contract_debit_diffs`)	The account a debit line posts to. On `contract_debits` this is a general ledger account; on `contract_debit_diffs` it’s a tenant account instead — same column name, different account type. Matches `accounts.account_number`, not `accounts.account_id`.	1 `accounts` row → many `contract_debits`/`contract_debit_diffs` rows
`creditor_id`	Identifies a creditor. Referenced by `technical_objects`, `property_creditor_services`, `service_contracts`, `booking_headers`, `booking_positions`, `orders`, and `offers`.	1 creditor → many rows across domains
`project_account_id`	Links a request, offer, or order to the project account it belongs to. Present on `projects` (one per project), `requests`, and `offers`; on `orders` the same value is called `project_reference_id`. Empty outside a project; on `requests` and `offers` a few values have no matching project.	1 project → 0..N requests/offers/orders
`technical_object_id`	Present on `notifications` and `orders`, resolves against `technical_objects.technical_object_id`. On both, not every value has a matching technical object — use a left join.	1 technical object → many notifications/orders
`report_id`	Links an order to the notification it was raised from.	1 notification → 0..N orders
`request_id`	Links an offer to the request for quotation it answers.	1 request → 0..N offers
`order_id` (on `offers`)	The order placed on the basis of an offer.	1 order → 0..1 offer
`service_contract_id`	Links a technical object to the service contract covering it. References `service_contracts.contract_id`.	1 contract → many technical objects
`person_id`	Links a booking to the tenant it applies to. Only valid combined with `property_id`, since the numbering restarts per property. A string on `tenants`, `booking_headers`, and `booking_positions`. Bookings link to a tenant only at the property level, not down to the individual unit — if the same tenant holds multiple units in one property, their bookings can’t be separated by unit.	1 person → 1..N tenancies per property
`floor_area_person_id`	Identifies a tenancy. Shared by `tenants`, `contract_debits`, `contract_ends`, and `index_rent` as the same underlying value and the same type (string) — join across them directly, without `property_id` and without a cast.	1 tenancy → many debit/end/index rows
`floor_area_id`	Identifies a unit in `property_structure`. Also present on `technical_objects`, `tenants`, `contract_debits`, `contract_ends`, `requests`, and `offers`.	1 unit → many rows
`asset_id`	Links a depreciation posting to the asset it writes down. Every `depreciation` row resolves against `assets`.	1 asset → many postings
`property_structure_account_id`	Foreign key into `property_structure`, present on `booking_headers`, `booking_positions`, and `technical_objects`. Always populated on the two booking tables, where it’s the only route from a booking down to a unit; on `technical_objects` it’s the fallback for rows without a `floor_area_id`.	1 unit → many rows

Cardinalities above describe the intended data model.

Key structure: composed, but not decomposable

The identifiers are hierarchical. Each one carries the identifier above it as a literal left prefix, so a tenancy key spells out which unit and which property it belongs to:

property_id                    1002
└─ floor_area_id               100210001         property_id + unit number
   └─ floor_area_person_id     100210001100001   floor_area_id + person_id

The key is built by appending: 1002 (property) + 10001 (unit number) = floor_area_id 100210001; 100210001 + 100001 (tenant number) = floor_area_person_id 100210001100001. Still, don’t parse it back apart to extract the components. Segment widths aren’t fixed — the same property can carry both 45111 and 451110 as floor_area_id, so 45111 is itself a prefix of 451110 and prefix matching is ambiguous. Building the key also drops separators, so a person_id of "010-1" ends up as the suffix 0101 and can’t be recovered. Read property_id, floor_area_id, and person_id directly instead of slicing the composite.

Get Started

Core Concepts

Guides

Data Model

Accounting

Contracts

Depreciation

KPI (Preview)

Operations

Property

Stakeholder

How the tables connect

Join keys in detail

Key structure: composed, but not decomposable

Accounting

Contracts

Depreciation

KPI (Preview)

Operations

Property

Stakeholder

​How the tables connect

​Join keys in detail

​Key structure: composed, but not decomposable

How the tables connect

Join keys in detail

Key structure: composed, but not decomposable