This guide is for third-party metering solution providers establishing a new data connection with the BuildingMinds Platform. It explains the integration approaches, the technical prerequisites your system should meet, and the meter data BuildingMinds expects — so a connection can be scoped and set up smoothly.

Integration approaches

Meter data can reach BuildingMinds in three ways. The right one is agreed in a short scoping exercise with the BuildingMinds team, which also defines the meter IDs in scope and how they map to assets (buildings, rental units, floors).

📘

One API integration serves one provider (1 API = 1 provider). Before building anything, BuildingMinds checks whether your provider is already covered through an existing integration or partner.

API requirements

For a direct API integration, your API should meet the following:

• Accessibility: Publicly accessible and secured via HTTPS.
• Historical data: Access to historical readings (real-time streaming is not required — BuildingMinds ingests historical and periodic data).
• Authentication: JWT bearer token or API key.
• Documentation: Clear documentation of the relevant endpoints, request parameters, and response formats.
• Testing: Access to real meters/data or a representative test data set; a sandbox environment is recommended for integration testing.
• Endpoints — at minimum:
  • Retrieve meters and their master data.
  • Retrieve meter readings, filterable by meter, date range, and interval.

Flat-file transfer requirements

• Format: CSV, following the template agreed during scoping (aligned with the API data formats).
• Consistency: One agreed structure per entity; data unaggregated and untransformed (see below).

Data BuildingMinds expects

The following applies to all integration methods. Keep data unaggregated and untransformed on your side — BuildingMinds performs aggregation and contextualisation. Where useful, the BuildingMinds vocabulary is shown so your fields map cleanly.

Meter master data

Static information about each meter:

• Provider meter ID: Your unique identifier for the meter (used to match readings and updates). Include the metering-point ID (e.g. MPAN, MPRN, SPID) where applicable.
• Meter category: Whether it's a main Meter, a Sub-meter, or a Virtual meter.
• Utility / resource type: e.g. Electricity, Gas, Heating, Water, Waste. (BuildingMinds groups these as Energy, Water, Waste, Fugitive.)
• Unit of consumption: e.g. kWh, m³, kg.
• Measurement kind: Cumulative (running total) or Delta (per-interval consumption).
• Purpose: What the meter measures — e.g. space heating, water heating, cooling, lighting, appliances.
• Procurement: Who procures the supply — e.g. self-procured or procured by a third party (landlord/tenant).
• Space served: e.g. tenant space, landlord space, shared/common space, whole building.
• Asset mapping: Which building / rental unit / floor the meter serves (defined during scoping).
• Data source & interval: e.g. smart meter at 15 / 30 / 60-minute intervals, or utility-provided monthly readings.
• Contract type: e.g. standard or green contract.
• Validity periods: Effective dates (validFrom / validUntil) when a meter's attributes change over time.
• Historical availability: How far back consumption data is available.

Helpful additional attributes

• Counts of main-meters and sub-meters per building.
• Meter mapping information describing how meters relate within a building.

Meter reading data

Dynamic consumption captured at regular intervals:

• Provider meter ID: Matches the meter in your master data.
• Measurement timestamp: In UTC (e.g. 2021-12-01T12:00:00Z).
• Interval / duration: The period the reading covers (e.g. 15 / 30 / 60 minutes).
• Value & unit: The measured value and its unit (e.g. 500 kWh, 12 m³).
• Measurement kind: Delta or Cumulative (consistent with the meter's master data).
• Accuracy / quality: e.g. Metered, Estimated, or Missing.
• Status flags: Indicators for null values, meter resets, or estimated values.

Data quality & error handling

These are recommended so BuildingMinds can interpret edge cases correctly:

• Flag null values and meters returning null.
• Detect and flag meter resets (and the negative deltas they can produce).
• Distinguish manual vs automated readings where possible.
• Communicate meter changes (replacements, re-configurations).
• Pass through quality information (estimated vs metered) rather than silently correcting it.

Getting started

1. Coverage check: BuildingMinds confirms whether your provider is already reachable via an existing integration or partner.
2. Scoping: If a new integration is needed, a scoping exercise defines the in-scope meter IDs and their mapping to assets.
3. Setup & validation: The integration is configured and validated for data quality before go-live.

For the platform's data formats and authentication, see the BuildingMinds API Getting Started guide.