Building data API: connecting building data to your own software

This article uses German rules as its legal example (Building Modernisation Act, BSI guidance, works council rights); other countries have their own. General information, not legal advice (status: October 2026).

Key points

• A building data API connects building automation, meters and room sensors with business software such as CAFM, CMMS, IWMS, ERP or BI, so that readings arrive where decisions are made. For software vendors, integrators and facility managers it is the precondition for using indoor climate and energy data.
• The protocol is rarely the hardest part. Most of the effort sits in the data model (which value belongs to which room, which asset, which unit) and in data quality.
• Germany already writes open interfaces into law: for non-residential buildings, section 56 of the Building Modernisation Act requires automation systems that make data accessible “via a common and freely configurable interface”, independent of any one manufacturer [1].
• Cyber security belongs in the architecture: network separation, encrypted transport and clear permissions are state of the art (BSI IT-Grundschutz INF.13 and INF.14, VDMA 24774, IEC 62443) [19–22].
• Room data such as CO₂ or occupancy can relate to individual people. In the EU the GDPR then applies, and in Germany the works council may have co-determination rights [24–27].

Why building data stays locked in silos, and what it costs

A typical commercial building runs several systems side by side: a building management system (BMS) for heating, ventilation and air conditioning; electricity and heat meters; room automation for lighting and blinds; some room sensors; a CAFM system (computer-aided facility management; related software categories are CMMS and IWMS) for spaces and work orders; and an ERP system for contracts and costs. Each has its own data formats, naming and often its own contractor.

The result is a set of data silos. The BMS knows the temperature in room “3.14”, the CAFM system knows the same room as “B-03-014”, and the energy meter is assigned to a plant item that has yet another name in both systems. Anyone asking whether a meeting room regularly overheats, which maintenance is due there and what energy it uses has to merge three systems by hand. Closing that gap is the job of a building data API: one documented, stable way for other software to read readings, states and master data from the building.

A study for the US National Institute of Standards and Technology (NIST) put a price on this. O’Connor, Dettbarn and Gilday estimated the cost of inadequate interoperability in the US capital facilities industry at 15.8 billion US dollars per year for 2002 [2]. Around two thirds of this was borne by owners and operators, and the largest share, about 9.1 billion US dollars, fell in the operations and maintenance phase [2]. The figure is old, US-only and limited to costs that could be quantified; the authors consider it likely to be conservative [2]. It shows where the effort lands: in decades of operation, not in construction.

Legislators have noticed too. In Germany, section 56 of the Building Modernisation Act (Gebäudemodernisierungsgesetz, GModG) requires non-residential buildings with heating, air-conditioning or combined heating or air-conditioning and ventilation systems above 70 kW rated output to be fitted with a building automation and control system by the end of 2029, where this is technically feasible and economically reasonable [1]. Among other things, this system must make the collected data accessible “via a common and freely configurable interface, so that analyses can be carried out independently of companies and manufacturers” (our translation) [1]. For new buildings the law also requires the system to work with other technical building systems, “including where different proprietary technologies, devices and manufacturers are used” [1].

For software vendors in facility and property management, the message is simple: operators want indoor climate and energy data in the software they already use, not in yet another portal.

Figure 1: An integration layer replaces many point-to-point links between data silos. Own illustration.

The three layers of a building data API

The word “interface” hides three layers that are often mixed up. Separating them makes projects easier to plan and price.

Layer 1: protocols and transport

The first layer is the technical connection: how do bits get from a device to the software? Building services use several protocols, each with its own purpose.

BACnet is standardised internationally as ISO 16484-5. It defines communication services and protocols for devices that monitor and control heating, ventilation, air conditioning, refrigeration and other building systems, with an object-oriented model of the information exchanged [8]; a temperature sensor appears as an object with properties such as present value and unit. BACnet Secure Connect (BACnet/SC) is a variant that carries messages over WebSockets and TLS with mutual authentication and encryption [9].

Modbus dates from 1979, when Modicon developed it for communication between controllers; an open specification for Modbus TCP/IP has existed since 1999 [10]. In buildings it is common on meters, heat pumps and inverters. It transfers register values whose meaning is defined in the manufacturer’s documentation. Since 2018 the Modbus Organization has described “Modbus Security”, a variant that wraps Modbus packets in TLS and uses X.509 certificates for authentication [11].

KNX is standardised as EN 50090 and ISO/IEC 14543-3 and is used mainly for room and electrical installation: lighting, blinds, heating and air conditioning [12].

MQTT is a lightweight publish/subscribe protocol. The OASIS specification describes it as a client-server messaging protocol for constrained devices and networks, such as in the Internet of Things [13]. Sensors publish values under a topic; any number of subscribers can receive it.

OPC UA (IEC 62541) is a platform-independent, service-oriented architecture from industrial automation. It brings its own information model and supports encryption, signatures and certificates [14].

REST/JSON APIs and webhooks are the everyday language of web and cloud software. A REST API is queried (“give me the values for room X since yesterday”); a webhook calls out on its own when an event occurs. The OpenAPI Specification describes such HTTP interfaces language-independently, so developers and tools can see what a service offers [15].

Table 1: Protocols and interface types in buildings. Security features only help if devices and installation actually use them.

The pattern: field protocols (BACnet, Modbus, KNX) are made for the local building network. For software running outside the building, an API is usually the better interface, with a gateway or platform translating in between.

Layer 2: data model and semantics

The second layer is meaning. “21.4” is worthless without context; “room temperature, room B-03-014, °C, measured at 10:05, air handling unit AHU 2” is usable. In existing buildings this context often lives only in point names that every installer builds differently.

Several open approaches address this:

• Brick Schema is an open-source project that describes the physical, logical and virtual parts of buildings and the relationships between them [6]. In the original paper by Balaji and colleagues (2016), the sensor metadata of six buildings with around 17,700 data points was mapped to Brick; eight applications then ran on all six buildings without modification [5]. That is a proof of concept on a few buildings, not evidence for any portfolio.
• Project Haystack is an open-source initiative for standardised semantic data models and web services for data from buildings and other connected systems [7].
• BACnet objects already provide a basic framework (object type, value, unit), but do not fully describe how rooms, plant and sensors relate to each other [8].
• IFC (Industry Foundation Classes) is the open, vendor-neutral standard for describing built assets digitally; the current version, IFC 4.3, is published as ISO 16739-1:2024 [16]. It can supply room IDs and areas from design and construction, but carries no live readings.

How demanding this layer is shows in a review by Pritoni and colleagues (2021) in the journal Energies. The authors found 40 metadata schemas and ontologies for buildings, examined five widely used ones in detail against three use cases, and concluded that modellers will find it “difficult, labor intensive, and costly” to create, sustain and use semantic models with existing ontologies [4].

Facility management has its own guidance too. In Germany, the GEFMA 400 series covers CAFM terms (GEFMA 400), IT integration interfaces of CAFM software (GEFMA 410), data management (GEFMA 430) and data exchange in FM (GEFMA 470); VDI/GEFMA 3814 Part 3.1 covers the interface between building automation and FM [3].

Layer 3: data quality

The third layer is the quality of the values. Gwerder and colleagues (2022) report that building automation data is often poor because of errors in installation, commissioning, data logging or metadata; design and service teams usually focus on control, not data acquisition [17]. They propose plausibility checks before analysis [17].

Lin and colleagues (2024) examined an Australian building with 731 data streams and found mixed sampling intervals (1, 5 or 10 minutes, or daily), gaps from network delays or sensor failures, hard-to-synchronise timestamps and inconsistent naming between buildings and even software versions [18]. This is a preprint based on a single building.

Typical data quality checks:

• Timestamps: unambiguous time zone and daylight saving (for example UTC with offset), time of measurement rather than receipt, synchronised clocks.
• Units: °C or K, kWh or Wh, ppm, µg/m³, sent with every record, not just documented.
• Gaps: missing values flagged as missing, not silently filled with zero or the last value.
• Metadata: room, plant item, quantity and device clearly assigned; changes (sensor moved, meter replaced) dated.
• Plausibility: values outside physically sensible ranges and frozen values detected.

Common integration mistakes and what they lead to

Projects that mix up the three layers tend to hit these problems.

Point-to-point links without a plan. Every new requirement gets its own interface: BMS to CAFM, meters to BI, sensors to a dashboard. Five systems allow up to ten links, each with its own mapping. When one system changes, several break at once.

Protocol chosen, meaning forgotten. A project decides “we’ll use MQTT” and later finds that every supplier structures topics and payloads differently. MQTT does not define the content of a message [13]; the project has to define the data model itself.

Raw data pushed into CAFM. A CAFM system is built for assets, spaces, work orders and contracts, not for millions of readings. Writing every sensor value into it every minute burdens database and users alike. Better: store only states, key figures or anomalies there and keep time series in a specialised platform.

Worked example (illustrative): data volume. Assumptions: 200 rooms, six quantities each (for example CO₂, temperature, humidity, particulate matter, VOC and light), one value every five minutes. That gives 200 × 6 × 288 = 345,600 values per day and around 126 million values per year. The figure depends heavily on the number of rooms and the interval, but it shows why time series and master data should be kept apart.

Building network exposed to the internet. Port forwarding to a BACnet or Modbus device is quick to set up. The secured variants, BACnet/SC and Modbus Security (2018), are recent additions [9][11] and not necessarily available in older installations. Without network separation, the building network becomes part of the attack surface.

Data protection as an afterthought. Occupancy or CO₂ values per single office can reveal things about individual employees. Discovering this after go-live makes rework expensive.

How to integrate building data step by step

Six steps from goal to operation

Start with the purpose, not the protocol. Figure 2 shows an order that works.

Figure 2: Typical steps of a building data integration project. Own illustration.

1. Define goals: “Which rooms are persistently poorly ventilated?” needs different data and intervals from “What was the monthly heat consumption per site?”.
2. Survey existing systems: systems, protocols, data points and contacts (installer, maintenance contractor, IT). A points list is the basis for everything else.
3. Define the data model: consistent room and plant IDs, units and time format; an open schema such as Brick or Haystack or a lean model of your own, depending on scale, with an unambiguous mapping to CAFM master data.
4. Connection and security: on-site gateway or direct cloud connection, network separation, access rights, encryption.
5. Check data quality: timestamps, gaps, plausibility, spot checks against the situation on site.
6. Operation: monitoring of data flows, API versioning, documented changes.

A broader BMS integration, bringing existing plant and new sensors into one data basis, follows the same six steps with more contractors involved.

BACnet and Modbus to the cloud: gateway or direct connection?

“BACnet cloud integration” or “Modbus to cloud” rarely means a new protocol. It means an architecture: a gateway in the building reads the field protocols locally and sends the values, encrypted, to a platform that offers them through an API. The field protocols stay on the building network.

Figure 3: Example architecture with separate network zones following the zone principle. Own illustration based on IEC 62443-3-2 [22].

Table 2: Two connection routes compared. Many buildings combine both.

A common pattern is BACnet to MQTT: the gateway polls BACnet objects locally and publishes the values as MQTT messages over TLS to a broker on the platform side. Service providers who want to offer the result under their own brand can build on BACnet to MQTT pipelines run by a specialist. Meters work the same way: a gateway reads the Modbus registers, converts them into readings with units and forwards them, the usual route for Modbus to cloud projects comparing energy across sites. MQTT is best as transport between gateway or sensor and platform; towards business software, a documented API is usually easier.

New sensor networks that send data by MQTT or similar protocols are covered under IoT sensors in facilities management.

CAFM, CMMS and IWMS integration: what goes where?

For CAFM, CMMS, IWMS and property management vendors, the question is not whether to connect readings but how much of them. A division that works:

• In CAFM/CMMS: master data (buildings, floors, rooms, plant), the assignment of sensors to rooms, states and anomalies (for example “CO₂ in room X above an agreed threshold on five days”), and the work orders that follow from them.
• In the data platform: time series at full resolution, trends, analyses, comparisons across sites.
• Through the API: on-demand queries of key figures and histories, webhook events when anomalies occur, and reading the room master data back from CAFM.

More on this under CAFM integration. In Germany, GEFMA 410 covers the IT integration of CAFM software in general [3].

Designing a sensor data API

Whether you offer a sensor data API yourself or consume someone else’s, a few properties matter:

• Structure by building, floor and room, not only by device, so that data still lines up after a device is replaced.
• Units and time zones in every record, not only in the documentation.
• Query and push combined: REST for histories and reports, webhooks for events.
• Described as an OpenAPI document, so that developers can generate clients and follow changes [15].
• Versioning and deprecation periods, so that integrations do not break without warning.
• Fine-grained permissions: a service provider sees only its sites, a tenant only its own floor space.

The same applies to an energy meter API: readings with units, intervals and meter IDs that stay stable when hardware changes. Whether it is called a “smart building API” or an “open API”, what counts is that it is documented, stable and usable by third parties, which is exactly what section 56 GModG means when it asks building automation systems for a “common and freely configurable” interface [1].

Cyber security for building systems

Building automation is operational technology, and securing it follows its own body of guidance:

• The German BSI IT-Grundschutz Compendium (the federal IT security agency’s baseline protection catalogue) contains two modules for buildings: INF.13 Technical Building Management and INF.14 Building Automation [19][20]. Both aim to make information security a fixed part of planning, implementation and operation [19][20].
• The VDMA specification 24774 “IT security in building automation” describes a practical approach: risk analysis, a life-cycle security concept, a separate building automation network, firewalls at segment boundaries, secured remote access, encrypted web and configuration interfaces, logging, updates and backups [21].
• The IEC 62443 series was developed for industrial automation and control systems. Its concept of “zones and conduits” groups system parts by risk and governs communication between them [22]. It transfers to building networks as a way of thinking, although the standard does not name building automation as its scope.

In practice: gateways sit in their own segment, connect outbound only, encrypt and stay read-only unless control has been agreed. Write access to controllers should be a deliberate, documented decision agreed with the installer.

GDPR: when room data becomes personal data

Under Art. 4(1) GDPR, personal data is any information relating to an identified or identifiable natural person; a person is identifiable if they can be identified directly or indirectly, for example by reference to location data [24]. CO₂, occupancy or noise values for a single office can therefore become personal data if it is known who sits there; in open-plan areas or with aggregated values this is less common.

Some design rules follow from this:

• Data protection by design (Art. 25 GDPR): collect only what is needed, choose time resolution and spatial assignment as coarse as possible, use pseudonymisation [25].
• Data protection impact assessment (Art. 35 GDPR): required where processing, in particular using new technologies, is likely to result in a high risk to the people concerned [26].
• Works council (Germany): under section 87(1) no. 6 of the Works Constitution Act (Betriebsverfassungsgesetz), the works council has a right of co-determination when technical equipment designed to monitor employees’ behaviour or performance is introduced [27]. Whether room sensors fall under this depends on the specific design and should be clarified early.
• Processors: if a platform provider processes data on the customer’s behalf, a contract or other legal act under Art. 28 GDPR is needed [23].

(General information, not legal advice, status: October 2026. In individual cases, data protection officers and legal advisers are the right contacts.)

Build or buy?

Software vendors can develop the connection to building systems themselves or use an existing platform via API. Both routes are legitimate; the choice depends less on technology than on core competence and operating effort.

Table 3: Criteria for building in-house or using a platform.

With a platform, contract and technology should ensure data can be exported at any time in an open format. That prevents lock-in and matches the manufacturer-independent analysis that section 56 GModG sets out [1].

How Nebatic helps

Nebatic makes data from its own devices (indoor climate, air quality, light, sound) and from connected systems available through APIs, for use in CAFM, BI or ESG software and your own applications. Access, scope and data structure are agreed per project. Depending on the project, Nebatic connects existing sensors, meters and building systems through suitable interfaces, working with the responsible installers and integrators.

For service providers who want to offer monitoring under their own brand, white-label operation is possible. How the collaboration with integrators and specialist contractors works is described under technology and service partners; offers for operators and service providers are under facility management.

Nebatic does not replace building automation, safety-relevant alarm systems or manufacturer maintenance. Installing conventional building automation remains the job of specialist contractors.

Limits and risks

A good interface makes data available, not correct. Wrongly mounted or assigned sensors give wrong conclusions even through a perfect API; plausibility and on-site spot checks remain necessary [17].

Open schemas such as Brick or Haystack ease reuse but bring their own modelling and maintenance effort [4]. For small portfolios a lean, documented in-house model can be more economical.

Write access to building automation (changing setpoints or operating modes from third-party software) interferes with control and possibly the installer’s warranty. It belongs with building services engineers and installers, under contract.

For IT security, data protection and GModG duties, the operator’s security officers, data protection officer (and works council) and energy consultants are the right advisers. The original text of the cited standards and guidelines is what counts.

Frequently asked questions

What is a building data API?

A defined interface through which readings, states and master data from building systems and sensors reach other software. It covers the protocol, a data model (which value belongs to which room and unit) and rules for access and security.

How do you integrate BACnet with the cloud?

Usually through a gateway that reads BACnet locally and sends the data, encrypted, to a platform with an API. BACnet/SC, a variant with TLS and certificates, suits IP networks with IT security requirements better [9].

Should I use BACnet or MQTT?

They do different jobs. BACnet is the field protocol of building automation, with an object model [8]. MQTT is a lightweight publish/subscribe transport from sensors or gateways to a platform and does not define message content [13], so a project needs its own data model. A common setup reads BACnet locally and forwards values by MQTT.

How do I get Modbus meter data into the cloud?

Through a gateway that polls the registers locally, converts them into readings with units and forwards them encrypted; you need the manufacturer’s register map. Exposing Modbus devices directly to the internet is not advisable.

What should an indoor air quality sensor API provide?

At minimum: the reading, its unit, a timestamp with time zone, a clear assignment to building, floor and room, and a flag for missing values. On top of that: a machine-readable description, for example following the OpenAPI Specification, versioning and a permissions model [15].

How does CAFM integration work for indoor climate data?

A data platform stores the time series; the CAFM, CMMS or IWMS system fetches only key figures, states or anomalies per room via API or receives them by webhook. Room IDs are matched with CAFM master data so that values and work orders land in the right room.

What does “open API” mean in building automation?

It usually means a documented interface that third parties can use, not necessarily one that is public and free of charge. For operators the point is that data can be analysed independently of the manufacturer; in Germany, section 56 GModG requires a “common and freely configurable interface” for building automation systems in non-residential buildings [1].

Sources

1. Federal Ministry of Justice / Federal Office of Justice (2026): Gebäudemodernisierungsgesetz (GModG), § 56 Gebäudeautomatisierung und Gebäudesteuerung. https://www.gesetze-im-internet.de/geg/__56.html
2. O’Connor, A. C.; Dettbarn, J. L.; Gilday, L. T. (2004): Cost Analysis of Inadequate Interoperability in the U.S. Capital Facilities Industry. NIST GCR 04-867. https://nvlpubs.nist.gov/nistpubs/gcr/2004/NIST.GCR.04-867.pdf
3. GEFMA – German Facility Management Association (2026): Complete list of GEFMA guidelines (as of 14 July 2026), 400 series (including GEFMA 400, 410, 430, 470; VDI/GEFMA 3814 Part 3.1). https://www.gefma.de/fileadmin/user_upload/richtlinie/00_Gesamtverzeichnis_2026-07-14.pdf
4. Pritoni, M.; Paine, D.; Fierro, G.; Mosiman, C.; Poplawski, M.; Saha, A.; Bender, J.; Granderson, J. (2021): Metadata Schemas and Ontologies for Building Energy Applications: A Critical Review and Use Case Analysis. Energies 14(7), 2024. https://bies.lbl.gov/publications/metadata-schemas-and-ontologies
5. Balaji, B. et al. (2016): Brick: Towards a Unified Metadata Schema for Buildings. BuildSys ‘16, ACM, pp. 41–50. https://par.nsf.gov/biblio/10048267
6. Brick Consortium: Brick Schema. https://brickschema.org/
7. Project Haystack: Project Haystack. https://project-haystack.org/
8. ISO (2022): ISO 16484-5:2022 Building automation and control systems (BACS) – Part 5: Data communication protocol (since replaced by ISO 16484-5:2026). https://committee.iso.org/standard/84964.html
9. BACnet International: BACnet Secure Connect (BACnet/SC). https://bacnetinternational.org/bacnetsc/
10. Modbus Organization: Modbus FAQ. https://www.modbus.org/faq
11. Modbus Organization (2018): Press release on Modbus Security (29 October 2018). https://www.modbus.org/docs/Modbus-SecurityPR-10-2018.pdf
12. Baunetz Wissen: KNX-Bussystem. https://www.baunetzwissen.de/elektro/fachwissen/gebaeudesystemtechnik/knx-bussystem-153108
13. OASIS (2019): MQTT Version 5.0, OASIS Standard, 7 March 2019. https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
14. OPC Foundation: Unified Architecture (OPC UA). https://opcfoundation.org/about/opc-technologies/opc-ua/
15. OpenAPI Initiative (2026): OpenAPI Specification v3.2.1. https://spec.openapis.org/oas/latest.html
16. buildingSMART International: Industry Foundation Classes (IFC). https://www.buildingsmart.org/standards/bsi-standards/industry-foundation-classes/
17. Gwerder, M.; Marek, R.; Melillo, A.; Husmann, M. (2022): Data Integrity Checks for Building Automation and Control Systems. CLIMA 2022. https://proceedings.open.tudelft.nl/clima2022/article/view/271
18. Lin, X.; Prabowo, A.; Razzak, I.; Xue, H.; Amos, M.; Behrens, S.; Salim, F. D. (2024): A Gap in Time: The Challenge of Processing Heterogeneous IoT Data in Digitalized Buildings. arXiv preprint 2405.14267. https://arxiv.org/abs/2405.14267
19. Federal Office for Information Security (BSI) (2023): IT-Grundschutz Compendium, module INF.14 Building Automation (Edition 2023). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/10_INF_Infrastruktur/INF_14_Gebaeudeautomation_Edition_2023.pdf?__blob=publicationFile&v=3
20. Federal Office for Information Security (BSI) (2023): IT-Grundschutz Compendium, module INF.13 Technical Building Management (Edition 2023). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-GS-Kompendium_Einzel_PDFs_2023/10_INF_Infrastruktur/INF_13_Technisches_Gebaeudemanagement_Edition_2023.pdf?__blob=publicationFile&v=3
21. VDMA Air Handling Technology Association (2026): Recommendation for tender texts based on VDMA specification 24774 “IT security in building automation”. https://www.vdma.eu/documents/d/group-34568/2026-03-vdma-fv-amg-empfehlung-ausschreibungstexte-basierend-auf-eb-24774
22. IEC Systems Committee Smart Energy: IEC 62443 – Background. https://syc-se.iec.ch/deliveries/cybersecurity-guidelines/security-standards-and-best-practices/iec-62443/
23. Regulation (EU) 2016/679 (GDPR), Art. 28 Processor (text edition; official text: https://eur-lex.europa.eu/eli/reg/2016/679/oj). https://gdpr-info.eu/art-28-gdpr/
24. Regulation (EU) 2016/679 (GDPR), Art. 4 Definitions (text edition). https://gdpr-info.eu/art-4-gdpr/
25. Regulation (EU) 2016/679 (GDPR), Art. 25 Data protection by design and by default (text edition). https://gdpr-info.eu/art-25-gdpr/
26. Regulation (EU) 2016/679 (GDPR), Art. 35 Data protection impact assessment (text edition). https://gdpr-info.eu/art-35-gdpr/
27. Federal Ministry of Justice / Federal Office of Justice: Betriebsverfassungsgesetz (Works Constitution Act), § 87 Rights of co-determination. https://www.gesetze-im-internet.de/betrvg/__87.html