What are Integrations?

Connect external systems to KODE OS to discover, collect, and act on building data

KODE OS integrations connect your building systems to a single platform. You configure a connector, discover devices and data points, and start collecting data — all from the Data Sources page in your building. With 200+ supported systems across access control, metering, occupancy, lighting, HVAC, and more, integrations give you a consistent view of every system in your portfolio.

​

What You Can Do

KODE OS integrations support five core capabilities. Each integration may support one or more of these depending on the external system.

​

Discover

Discovery is a user-initiated process that automatically finds devices, points, schedules, and other assets from a connector without requiring manual configuration of each item. KODE OS queries the external system to list all available sensors, cameras, door readers, meters, and more.

• Devices and Points: KODE OS queries the connector for available devices and their data points
• Schedules: If supported, KODE OS discovers schedules or calendars configured within the third-party system
• Assets: Non-sensor metadata objects like furniture, network equipment, or safety equipment

For more details, see the Discovery guide.

​

Collect

Collect refers to the process of gathering data about discovered entities. Depending on the external system, this can happen in two ways:

• Scheduled Pull: KODE OS connects to the Connector at regular intervals to pull data. Protocols used include REST APIs, SOAP APIs, FTP/SFTP, SDKs, and OpenSSL/TCP.
• Real-Time Push: The third-party system pushes data immediately as events occur. Protocols include MQTT, WebSockets, and Webhooks.

Data collection supports three types:

• Snapshot: A single view of the current state at a specific moment
• Delta: Only the changes in value since the last collection
• Historical: A complete log of past values over time

For more details, see the Data Collection guide.

​

Actions

Actions are commands sent to devices or requests made to external systems to initiate a change or trigger an event. KODE OS supports:

• Point Actions: Directly changing a device’s behavior by setting a new value to a Point (e.g., setting thermostat temperature, turning a light on for 2 hours)
• Entity Actions: Creating or updating records in external systems (e.g., creating a work order)
• Schedule Actions: Creating, updating, or deleting schedules in the external system

For more details, see the Actions guide.

​

Schedules

Schedules allow you to manage time-based configurations in external systems. KODE OS supports two schedule types:

• Calendar Schedules: Handle exceptions or one-time events — holidays, maintenance windows, temporary overrides
• Weekly Schedules: Define recurring routines for each day of the week — business hours, off-hours, weekend settings

For more details, see the Schedules guide.

​

Asset Discovery

Assets are physical or virtual objects that KODE OS tracks for metadata purposes — unlike devices, they do not have time-series data points. Asset discovery finds and catalogs items like network equipment, furniture, fire safety equipment, and other inventory. For more details, see the Discovery guide.

​

How It Works

The integration lifecycle follows a consistent flow regardless of which external system you are connecting to.

​

Navigate to Data Sources

Open KODE OS and go to your specific building or site. On the left-side menu, click Data Sources. The Connectors page displays any existing connectors you have configured.

​

Browse the API Catalog

On the left, click API Catalog. The API Catalog page categorizes available APIs by system type. Use the search bar at the top right to find your desired API. Clicking on an API displays its supported entities, scheduled data collection intervals, and available fields.

​

Add a Datasource

At the top right of the API details page, click + Add Datasource. A dialog opens with the required and optional fields for that specific connector type. From this point, follow the guidance in the specific integration guide for the API you are integrating.

​

Configure the Connector

Enter the required credentials, URLs, and configuration settings. These vary by integration — see the individual integration page for the exact fields and where to obtain each value.

​

Discover Devices and Points

Once the connector is configured, run discovery to automatically find all available devices and their data points from the external system.

​

Start Collecting Data

With devices and points discovered, KODE OS begins collecting data according to the configured polling frequency. Navigate to Cloud BMS to add ontology to devices for consistency across your building portfolio.

​

Core Concepts

Before working with integrations, it helps to understand the key terms used throughout KODE OS.

​

What’s an API?

An API (Application Programming Interface) is a communication bridge that allows different software applications or devices to understand and interact with each other. KODE OS uses APIs to exchange data with external building systems.

​

What’s a Connector (Datasource)?

Different devices from various manufacturers often use different communication protocols like MQTT, Modbus, or HTTP/s. A Connector, also known as a Datasource, is a software component specifically designed to understand and communicate with a particular group of devices from the same brand or type. It acts as the source from which KODE OS fetches or sends data to those devices.

​

Device

A Device is the physical piece of hardware in the real world, such as a thermostat, a smart light bulb, or a motion sensor. Each device connects to the KODE OS system through a Connector. Devices are the physical entities you ultimately aim to control or monitor.

​

Point (API Endpoint)

A Point represents an individual data value, measurement, or control option associated with a Device. Points are the specific readings and controls on your device:

• A temperature reading (22.5°C)
• A command (e.g., turn_on_light)
• A status (e.g., door_open, battery_low)

​

Sensor Data

Data collected from physical sensors on devices — these are measurable, often time-stamped values pulled directly from devices and their individual points. Sensor data is typically used for monitoring, analytics, or triggering actions within the platform based on device behavior.

• Room temperature reported by a thermostat every few minutes
• Occupancy detection from a motion sensor in a meeting room
• Air quality levels (CO₂ or VOC) measured by environmental sensors
• Water flow detection from a sensor monitoring restroom usage or leaks

​

Non-Sensor Data

Non-sensor data refers to important building information that is not generated by a physical sensor. This data is typically generated by people, external systems, or actions and is often stored for tracking, reporting, or compliance purposes.

• People making reservations
• Visitors entering a building
• Alarms being triggered
• Maintenance workers completing inspection checklists

​

Schedules

A Schedule is a configuration that defines a set of rules or a calendar for automating actions within the system based on time. It tells the system what to run, when to run it, and how often.

• Lights automatically turning off at 8 PM
• HVAC systems starting at 6 AM on weekdays

​

Ontology

In KODE OS, ontology refers to the common vocabulary and structured framework used to name and organize devices, points, and other entities discovered from different external systems. Each vendor may use different naming conventions for the same type of object: Without ontology, you would need to know each vendor’s naming scheme to work with the data. Ontology maps these disparate names to a standardized type within KODE OS (for example, all three of the above map to a “Temperature Sensor” device type with a “Temperature” point type). The ontology workflow follows this sequence:

1. Discover — KODE OS finds devices and points from the external system and saves each item’s native identifier
2. Map — The system maps each discovered object to a standardized type, either automatically during discovery or manually in Cloud BMS
3. Operate — Once mapped, you collect data, trigger actions, and monitor devices using consistent names regardless of the vendor

You apply ontology in Cloud BMS after discovering devices from a connector.

​

Dynamic APIs

Some external systems — such as Niagara or BACnet servers — do not have a fixed API structure. Instead of predefined device and point types, they expose a dynamic structure where available objects are discovered at runtime. New devices and points can appear without requiring changes to the integration definition. For dynamic integrations, the workflow differs slightly:

1. Connect — KODE OS connects to the external system
2. Discover — KODE OS dynamically reads all available objects from the system
3. Map — Because automatic ontology mapping may not be possible for dynamic structures, you manually map each discovered object to a standard type in Cloud BMS
4. Operate — After mapping, you collect data, perform actions, and monitor these objects as with any other integration

​

Communication Protocols

To interact with external systems — whether collecting data, controlling devices, or syncing information — KODE OS utilizes various communication methods. The specific method depends on the capabilities and standards of the external API.

​

REST

REST (Representational State Transfer) is the most common architectural style for web APIs. It works over HTTP/s and uses standard methods like GET, POST, PUT, and DELETE. You send a request and get data back, typically in JSON format.

​

SOAP

SOAP (Simple Object Access Protocol) is an XML-based messaging protocol often used in legacy systems. It adheres to strict standards defined by a Web Services Description Language (WSDL) file.

​

Webhook

A Webhook is a method where the external system sends an automated HTTP request to a predefined URL in KODE OS when a specific event occurs. This is push-based — the third-party system automatically pushes data to you as soon as something happens.

​

MQTT

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for constrained devices and low-bandwidth networks. It uses a publish/subscribe model with topics — a temperature sensor might publish its reading to a specific topic every few seconds.

​

WebSocket

WebSocket provides full-duplex communication over a single TCP connection, allowing for real-time, bidirectional data exchange. Both sides can send and receive messages instantly without needing to initiate a new request each time.

​

SDK

An SDK (Software Development Kit) is a collection of software development tools, libraries, and code samples provided by the external system’s vendor. An SDK provides clearly labeled functions to interact with the system directly.

​

OpenSSL / TCP Commands

This method involves raw socket communication, often used for custom or low-level integrations with encrypted devices or systems that do not support standard protocols.

​

SFTP / FTP

FTP and SFTP are protocols used for transferring files between systems. Some legacy systems exchange data via scheduled file transfers (e.g., CSV or XML files) rather than real-time APIs.

​

Modbus / BACnet

Modbus and BACnet are standard communication protocols primarily used in building automation systems to communicate with physical devices like HVAC units, meters, and controllers. Modbus works over serial (RS485) or TCP/IP, while BACnet is the standard protocol for building automation and control networks.

​

Environments

The environment encompasses all the surrounding infrastructure — systems, servers, network settings, and tools — that enable your IoT system to function correctly.

​

Cloud vs. Local (On-Premises)

• Cloud: Connectors, databases, and servers are hosted on third-party platforms (AWS, GCP, Azure), accessible over the internet. Offers scalability and flexibility but requires strong cybersecurity practices.
• Local (On-Premises): Servers and databases are physically installed within the building or client premises. Provides more direct control over security and is sometimes required for compliance or privacy reasons. May require VPN access for communication with KODE OS.

​

Key Infrastructure Components

• Servers: Machines where your connectors and APIs are installed and run
• Databases: Storage locations for device and point data, such as sensor readings
• Network: Communication pathways (Wi-Fi, wired Ethernet, VPN tunnels) that allow devices and servers to communicate
• IP / URL: Addresses used by devices and servers to locate each other — an IP address is the exact street address, a URL is the human-readable nickname
• Credentials / Certificates: Passwords, API keys, and digital certificates used to securely authenticate and communicate
• Firewalls: Network security systems that control incoming and outgoing traffic, allowing only approved devices to communicate
• API Gateways: Systems that manage, secure, and route API communications — handling authentication, rate limiting, and request routing

​

Next Steps