# Glossary Source: https://cumulocity.com/docs/glossary/ Sector: Getting started Release: Latest This glossary provides definitions for key terms and concepts used in the Cumulocity platform and throughout the Cumulocity documentation. Use this page to quickly find clear explanations for Cumulocity products, features, and technical language. ## A ### Administration application {#administration-application} The Administration application is a default Cumulocity application and the central place for platform administrators to manage a tenant. It is used to govern a [tenant](https://cumulocity.com/docs/glossary/#tenant) by managing [users](https://cumulocity.com/docs/glossary/#user), [roles](https://cumulocity.com/docs/glossary/#role), and [permissions](https://cumulocity.com/docs/glossary/#permission), subscribing to and managing [applications](https://cumulocity.com/docs/glossary/#application) and [microservices](https://cumulocity.com/docs/glossary/#microservice), and configuring tenant-level settings such as retention rules, custom properties, and [branding](https://cumulocity.com/docs/glossary/#branding). See also [Platform administration](https://cumulocity.com/docs/sector/platform_administration/) in the documentation. **Developer details** The Administration application utilizes various REST APIs for its functionality, such as the [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/...`) for users/roles, [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (`/tenant/...`) for tenant settings/options, and [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`/application/...`) for application/microservice management. Many settings configured in the UI, such as branding and feature toggles, are stored as key-value pairs and can be managed via the [Tenant Options API](https://cumulocity.com/api/core/#tag/Options) (`/tenant/options`). ### Alarm {#alarm} An alarm indicates a condition that requires action from a user or system. Alarms have a lifecycle status (ACTIVE, ACKNOWLEDGED, CLEARED) and a severity (CRITICAL, MAJOR, MINOR, WARNING), and are explicitly tracked within the platform until they are resolved. See also [Working with alarms](https://cumulocity.com/docs/device-management-application/monitoring-and-controlling-devices/#working-with-alarms) in the documentation. **Developer details** Alarms are technically a specialized type of event, managed via the [Alarm API](https://cumulocity.com/api/core/#tag/Alarms) (/alarm/alarms). Key properties include type, text, time, status (ACTIVE, ACKNOWLEDGED, CLEARED), and severity (CRITICAL, MAJOR, MINOR, WARNING). Creating an alarm uses POST, and updating status uses PUT on `/alarm/alarms/{alarmId}`. SmartREST templates (for example, 301-304) simplify creation over MQTT/HTTP. ### Analytics Builder {#analytics-builder} Analytics Builder is a tool in the [Cumulocity Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics) application for designing real-time analytics models in a graphical, drag-and-drop environment. By combining pre-built [blocks](https://cumulocity.com/docs/glossary/#block), you can quickly build [models](https://cumulocity.com/docs/glossary/#model) to transform streaming IoT data, generate new data, create alerts, or trigger device [operations](https://cumulocity.com/docs/glossary/#operation). See also [Analytics Builder](https://cumulocity.com/docs/streaming-analytics/analytics-builder/) in the documentation. **Developer details** Analytics Builder models are created in the user interface, not via the API. Tenant options affecting the behaviour of Analytics Builder are listed in the Analytics Builder [Configuration](https://cumulocity.com/docs/streaming-analytics/analytics-builder/#configuration) documentation. You can use the [Analytics Builder Block SDK](https://github.com/Cumulocity-IoT/apama-analytics-builder-block-sdk) to write, test, and package custom blocks and to upload these blocks into Analytics Builder. ### Apama {#apama} Apama is the high-performance event processing engine that powers [Cumulocity Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics). It enables real-time analytics, forming the foundation for smart rules, [Analytics Builder´s](https://cumulocity.com/docs/glossary/#analytics-builder) drag-and-drop models as well as custom [EPL apps](https://cumulocity.com/docs/glossary/#epl-apps). **Developer details** EPL code running in the Apama engine interacts with Cumulocity using EPL APIs (for example, the `com.apama.cumulocity` package) to send and receive platform data. The deployment of EPL files (.mon) is managed via the Streaming Analytics UI or the [EPL Apps Tools](https://github.com/Cumulocity-IoT/apama-eplapps-tools). Diagnostics and monitoring are available via dedicated endpoints like `/service/cep/diagnostics` or using Prometheus as described in [Troubleshooting and diagnostics](https://cumulocity.com/docs/streaming-analytics/troubleshooting/#monitoring-rest). ### Application {#application} An application is a component integrated with the platform that delivers user interfaces (= [web application](https://cumulocity.com/docs/glossary/#web-application)), business logic (= [microservice](https://cumulocity.com/docs/glossary/#microservice)), or both, to enable, extend, or customize IoT solutions. Applications bridge device data with user workflows and business processes, supporting use cases such as remote monitoring, predictive maintenance, [asset](https://cumulocity.com/docs/glossary/#asset) tracking, and smart automation. Cumulocity's application enablement tools empower both business users and developers to build and deploy custom applications. See also [Application enablement](https://cumulocity.com/docs/app-intro/applications/) in the documentation. **Developer details** Applications (web apps, microservices) are managed via the [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`/application/applications`). This includes creating (POST), retrieving (GET), updating (PUT), deleting (DELETE), and copying (POST /clone). Application versions (`/application/applications/{id}/versions`) and binaries (`/application/applications/{id}/binaries`) also have dedicated endpoints. ### Application availability {#application-availability} Application availability defines how a custom application or [microservice](https://cumulocity.com/docs/glossary/#microservice) can be shared and accessed. A superior tenant (that is, an [Enterprise tenant](https://cumulocity.com/docs/glossary/#enterprise-tenant) or the [Management tenant](https://cumulocity.com/docs/glossary/#management-tenant))) manages this availability to share applications with its [subtenants](https://cumulocity.com/docs/glossary/#subtenant). **Developer details** Application availability is managed via the [Application API](https://cumulocity.com/api/core/#tag/Application-API) (/application/applications) and can be changed via a PUT request. ### Application switcher {#application-switcher} The application switcher is a UI component that shows all Cumulocity [applications](https://cumulocity.com/docs/glossary/#application) the user has access to and allows switching between these applications. **Developer details** The application switcher UI lists applications accessible to the user. This list is populated based on user permissions and tenant subscriptions, retrieved via `GET /application/applications?user={userId}`. The application manifest property `noAppSwitcher` (managed via the [Application API](https://cumulocity.com/api/core/#tag/Application-API)) can be used to hide an application from the switcher. ### Asset {#asset} An asset is the digital representation of a business object within the Cumulocity [inventory](https://cumulocity.com/docs/glossary/#inventory), such as a machine, building, or vehicle. Technically, an asset is a [managed object](https://cumulocity.com/docs/glossary/#managed-object) that can be structured into a logical hierarchy (the [asset hierarchy](https://cumulocity.com/docs/glossary/#asset-hierarchy)) using child asset relationships. Assets can take several forms: simple [groups](https://cumulocity.com/docs/glossary/#group) used for organization, [devices](https://cumulocity.com/docs/glossary/#device) that send telemetry data, or complex custom assets defined by an [asset definition](https://cumulocity.com/docs/glossary/#asset-model) in the [Digital Twin Manager (DTM)](https://cumulocity.com/docs/glossary/#dtm). See also [Digital Twin Manager](https://cumulocity.com/docs/dtm/dtm-introduction/) in the documentation. **Developer details** Assets are represented as managed objects in the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`). They use the `childAssets` property and associated endpoints (`/inventory/managedObjects/{id}/childAssets`) for hierarchy management. Assets created via the the Digital Twin Manager application are enriched with custom fragments defined by their asset definition. ### Asset hierarchy {#asset-hierarchy} An asset hierarchy is a structure within the [inventory](https://cumulocity.com/docs/glossary/#inventory) that organizes [assets](https://cumulocity.com/docs/glossary/#asset) (based on [asset definitions](https://cumulocity.com/docs/glossary/#asset-model)) and [devices](https://cumulocity.com/docs/glossary/#device) to reflect their logical or business relationships, such as a factory containing production lines, which in turn contain individual machines. The asset hierarchy is built by nesting assets with one another to form parent-child relationships ([child assets](https://cumulocity.com/docs/glossary/#child-asset)). It is fundamentally distinct from the [communication hierarchy](https://cumulocity.com/docs/glossary/#communication-hierarchy), which models the physical network topology ([child devices](https://cumulocity.com/docs/glossary/#child-device)). See also [Asset hierarchy](https://cumulocity.com/docs/dtm/asset-hierarchy/) in the documentation. **Developer details** The asset hierarchy is composed of managed objects linked via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API)'s child asset endpoints: `GET /inventory/managedObjects/{id}/childAssets`, `POST /inventory/managedObjects/{id}/childAssets`, and `DELETE /inventory/managedObjects/{id}/childAssets/{childId}`. The DTM application is supported by a dedicated dtm-ms microservice and API (for example, `/service/dtm/...`) for managing the underlying asset and property definitions. ### Asset definition {#asset-model} An asset definition is a reusable blueprint defined in the [Digital Twin Manager (DTM)](https://cumulocity.com/docs/glossary/#dtm) that specifies the structure, properties, and relationships of a particular type of [asset](https://cumulocity.com/docs/glossary/#asset). It includes a unique key and label, [property definitions](https://cumulocity.com/docs/glossary/#asset-property), and optionally references to [child asset](https://cumulocity.com/docs/glossary/#child-asset) definitions to support the composition of [asset hierarchies](https://cumulocity.com/docs/glossary/#asset-hierarchy) (for example, a wind turbine model composed of rotor and tower sub-models). Once published, an asset definition governs how assets of that type are created, validated, and visualized across Cumulocity [applications](https://cumulocity.com/docs/glossary/#application). See also [Asset definitions](https://cumulocity.com/docs/dtm/asset-types/) in the documentation. **Developer details** Assets are represented as managed objects in the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`). They use the child assets property and associated endpoints (`/inventory/managedObjects/{id}/childAssets`) for hierarchy management. Specific asset characteristics are defined using custom JSON fragments. See also [Asset definitions](https://cumulocity.com/api/dtm/#tag/Asset-Definitions). ### Property definition {#asset-property} Property definitions are configurable attributes within an [asset definition](https://cumulocity.com/docs/glossary/#asset-model) that define, describe, and enrich an [asset´s](https://cumulocity.com/docs/glossary/#asset) characteristics (for example, *tower height* in a wind turbine model). They can be of various data types, such as text, number, date, file, boolean, complex object, or custom. Property definitions may be simple (single values), complex (nested structures), or custom (additional metadata), and they act as reusable building blocks to ensure consistent data structures, metadata enrichment, and governed information across assets. ### Audit log {#audit-log} An audit log is a record of a security-relevant action performed on the platform. Audit logs are a special type of [event](https://cumulocity.com/docs/glossary/#event) that includes details about who performed an action (can be a human [user](https://cumulocity.com/docs/glossary/#user), a [device](https://cumulocity.com/docs/glossary/#device), a [microservice](https://cumulocity.com/docs/glossary/#microservice) or the platform itself), the [application](https://cumulocity.com/docs/glossary/#application) used, the activity itself, and the severity. They provide a chronological and immutable trail of [operations](https://cumulocity.com/docs/glossary/#operation) for security analysis and compliance auditing. See also [Audit logs](https://cumulocity.com/docs/standard-tenant/monitoring/#audit-logs) in the documentation. **Developer details** Audit logs are managed via the [Audit API](https://cumulocity.com/api/core/#tag/Audits ). Records can be created via `POST /audit/auditRecords` and retrieved via `GET /audit/auditRecords`, with filtering by user, type, application, and date range. Creating an audit record requires ROLE_AUDIT_ADMIN or AUDIT_ADMIN permission. ### Authentication {#authentication} Authentication is the process of verifying the identity of a [user](https://cumulocity.com/docs/glossary/#user), [device](https://cumulocity.com/docs/glossary/#device), or [application](https://cumulocity.com/docs/glossary/#application) attempting to access the Cumulocity platform. Cumulocity supports multiple authentication methods, including basic authentication, OAI-Secure (an OAuth2-based implementation), and Single sign-on (SSO) integration with external identity providers. See also [Authentication](https://cumulocity.com/docs/authentication/basic-settings/) in the documentation. **Developer details** All available authentication methods are configured in the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) via the REST endpoints `PUT /tenant/loginOptions` (CREATE) and `POST /tenant/loginOptions/{typeOrId})` (UPDATE). ### Authorization {#authorization} Authorization is the process of determining whether an [authenticated](https://cumulocity.com/docs/glossary/#authentication) identity ([user](https://cumulocity.com/docs/glossary/#user), [device](https://cumulocity.com/docs/glossary/#device), or [application](https://cumulocity.com/docs/glossary/#application)) has the necessary [permissions](https://cumulocity.com/docs/glossary/#permission) to access a specific resource or perform a particular action. Authorization in Cumulocity is managed through a [Role-Based Access Control (RBAC)](https://cumulocity.com/docs/glossary/#rbac) model, in which permissions are bundled into [global roles](https://cumulocity.com/docs/glossary/#global-role) and [inventory role](https://cumulocity.com/docs/glossary/#inventory-role). **Developer details** Authorization is enforced by the platform based on roles assigned to users. These roles and their associated permissions are defined and managed via the [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/roles`, `/user/inventoryroles`). ### Availability {#availability} Availability refers to the monitoring of the connection status of a [device](https://cumulocity.com/docs/glossary/#device) to indicate whether it is ONLINE, OFFLINE, or its status is UNKNOWN. This status is determined by device communication patterns, such as the periodic sending of data or the maintenance of a push connection. **Developer details** The connection status is exposed via the `c8y_Connection` fragment within a device's managed object. The monitoring behavior is configured via the `c8y_RequiredAvailability` fragment, which specifies the required response interval in minutes. ## B ### Block (Analytics Builder) {#block} Blocks are the basic processing units of an Analytics Builder [model](https://cumulocity.com/docs/glossary/#model). Each block implements some predefined functionality, such as receiving data from a sensor, performing a calculation, detecting a condition, or generating an output signal, and processes data accordingly. Each block has a number of inputs, outputs and configurable parameters. [Analytics Builder](https://cumulocity.com/docs/glossary/#analytics-builder) comes with a set of prebuilt blocks. **Developer details** You can use the [Analytics Builder Block SDK](https://github.com/Cumulocity-IoT/apama-analytics-builder-block-sdk) to write, test, and package custom blocks and to upload these blocks into Analytics Builder. ### Branding {#branding} Branding is a feature, typically available in [Enterprise tenants](https://cumulocity.com/docs/glossary/#enterprise-tenant) or the relevant add-ons, that enables organizations to customize the platform's user interface to align with their corporate identity. This includes modifying logos, colors, fonts, and the application's domain name to provide a consistent, customized user experience. **Developer details** Branding settings are managed in a file called *options.json* in the branding application. This file contains a JSON object with keys for colors, logos, fonts, and other UI elements which can be configured by administrators. ### Bulk device registration {#bulk-device-registration} Bulk device registration is a method for registering larger quantities of [devices](https://cumulocity.com/docs/glossary/#device) into the Cumulocity platform by uploading a CSV file containing device details, rather than registering each device individually. ## C ### CCU (Cumulocity Compute Unit) {#ccu} CCU (Cumulocity Compute Unit) is a standardized measure for computational resources consumed by custom [microservices](https://cumulocity.com/docs/glossary/#microservice) deployed by a customer. 1 CCU typically equates to 1 CPU core and 4 GiB of memory. CCUs are calculated based on daily average resource usage and used for billing purposes. The CCU calculation takes into account the resources denoted in the [microservice manifest](https://cumulocity.com/docs/glossary/#microservice-manifest) and the subscribed time for each microservice. **Developer details** The calculation is performed offline for billing based on resource requests in the *cumulocity.json* manifest. Aggregated data can be viewed in usage statistics reports accessible via the Tenant Statistics API. ### Change logs {#change-logs} Change logs are the official record of Cumulocity product changes and announcements, published for all cloud deployments ([Continous Deployment](https://cumulocity.com/docs/glossary/#continuous-deployment)), detailing updates such as new features, improvements, and API changes or deprecations. Corresponds to the [release notes](https://cumulocity.com/docs/glossary/#release-notes) in the [Yearly releases](https://cumulocity.com/docs/glossary/#yearly-release). See [Change logs](https://cumulocity.com/docs/change-logs/). ### Child asset {#child-asset} Child assets denote a relationship type within the Cumulocity [inventory](https://cumulocity.com/docs/glossary/#inventory)'s [domain model](https://cumulocity.com/docs/glossary/#domain-model) used to establish parent-child links between [managed objects](https://cumulocity.com/docs/glossary/#managed-object). This relationship forms the [asset hierarchy](https://cumulocity.com/docs/glossary/#asset-hierarchy), connecting a parent asset or [group](https://cumulocity.com/docs/glossary/#group) to its subordinate [assets](https://cumulocity.com/docs/glossary/#asset) or [devices](https://cumulocity.com/docs/glossary/#device) from a business or logical perspective. **Developer details** The child assets relationship is managed via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API). Key endpoints include: `GET /inventory/managedObjects/{id}/childAssets`, `POST /inventory/managedObjects/{id}/childAssets`, and `DELETE /inventory/managedObjects/{id}/childAssets/{childId}`. ### Child device {#child-device} Child devices denote a relationship type within the Cumulocity [inventory](https://cumulocity.com/docs/glossary/#inventory)'s [domain model](https://cumulocity.com/docs/glossary/#domain-model) used to establish parent-child links that reflect the [communication hierarchy](https://cumulocity.com/docs/glossary/#communication-hierarchy), connecting a parent device (often an agent or a gateway) to the downstream [devices](https://cumulocity.com/docs/glossary/#device) it manages. **Developer details** The child devices relationship is managed via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API). Key endpoints include: `GET /inventory/managedObjects/{id}/childDevices`, `POST /inventory/managedObjects/{id}/childDevices`, and `DELETE /inventory/managedObjects/{id}/childDevices/{childId}`. ### Client ID {#client-id} A client ID is a unique identifier for a device, client, or gateway connecting to a [protocol adapter](https://cumulocity.com/docs/glossary/#protocol-adapter). The client ID must be unique within a Cumulocity [tenant](https://cumulocity.com/docs/glossary/#tenant). For example, devices connecting to the [MQTT Service](https://cumulocity.com/docs/glossary/#mqtt-service) use the MQTT client identifier as their client ID. ### Cockpit application {#cockpit-application} The Cockpit application is one of the default [applications](https://cumulocity.com/docs/glossary/#application) of Cumulocity. It provides a self-service UI to manage and monitor IoT assets and data from a business perspective, like managing [assets](https://cumulocity.com/docs/glossary/#asset), visualizing data, working with [dashboards](https://cumulocity.com/docs/glossary/#dashboard) and managing [reports](https://cumulocity.com/docs/glossary/#report). See also [Cockpit](https://cumulocity.com/docs/cockpit/) in the documentation. **Developer details** The Cockpit UI uses core REST APIs: [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`) for assets/groups, [Measurement API](https://cumulocity.com/api/core/#tag/Measurements ) (`/measurement/measurements`), [Event API](https://cumulocity.com/api/core/#tag/Events) (`/event/events`), [Alarm API](https://cumulocity.com/api/core/#tag/Alarms) (`/alarm/alarms`). Cockpit-specific configurations like dashboards are stored as managed objects. ### Communication hierarchy {#communication-hierarchy} The communication hierarchy models how [devices](https://cumulocity.com/docs/glossary/#device) are connected to the platform from a network communication perspective. It is built using the [child devices](https://cumulocity.com/docs/glossary/#child-device) relationship, with agents or gateways typically forming the root of the hierarchy. This structure reflects the physical or network topology, as opposed to the logical business structure represented by the [asset hierarchy](https://cumulocity.com/docs/glossary/#asset-hierarchy). See also [Cumulocity's domain model](https://cumulocity.com/docs/concepts/domain-model/#object-hierarchies) in the documentation. **Developer details** The communication hierarchy is managed via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) endpoints `GET /inventory/managedObjects/{id}/childDevices`, `POST /inventory/managedObjects/{id}/childDevices`, and `DELETE /inventory/managedObjects/{id}/childDevices/{childId}`. ### Configuration management {#configuration-management} The configuration management feature allows administrators and [applications](https://cumulocity.com/docs/glossary/#application) to remotely manage the settings of a [device](https://cumulocity.com/docs/glossary/#device). This is typically achieved by creating and applying a configuration operation. See also [Managing configurations](https://cumulocity.com/docs/device-management-application/managing-device-data/#managing-configurations) in the documentation. **Developer details** Configuration management is primarily handled via the [Device Control API](https://cumulocity.com/api/core/#tag/Device-control-API). A configuration update is sent by creating an operation via `POST /devicecontrol/operations` containing a `c8y_Configuration` fragment. For larger files, the configuration can be uploaded via `POST /inventory/binaries` and referenced in the operation. ### Connection monitoring {#connection-monitoring} The connection monitoring feature allows identifying [devices](https://cumulocity.com/docs/glossary/#device) that have stopped communicating with the Cumulocity platform. The connection status (ONLINE/OFFLINE) is determined by monitoring device heartbeats or tracking the status of a persistent push connection. **Developer details** The connection status is exposed via the `c8y_Connection` fragment within a device's managed object. The monitoring behavior is configured via the `c8y_RequiredAvailability` fragment. If a device fails to communicate, the platform updates `c8y_Connection.status` to UNAVAILABLE. ### Continuous Deployment model {#continuous-deployment} In the Cumulocity Continuous Deployment (CD) model, the different components of the Cumulocity platform are updated on a continuous basis. This means a frequent deployment of small incremental improvements. The changes are communicated via the [change logs](https://cumulocity.com/docs/glossary/#change-logs). See also [Private Preview](https://cumulocity.com/docs/glossary/#private-preview), [Public Preview](https://cumulocity.com/docs/glossary/#public-preview) and [General Availability](https://cumulocity.com/docs/glossary/#ga). ### Cumulocity CLI (Command Line Interface) {#cumulocity-cli} The Cumulocity CLI (Command Line Interface) is a software tool provided by Cumulocity that offers a command-line interface for interacting with the platform. It enables developers, administrators, and automation scripts to manage platform resources directly from a terminal. See also the [CLI documentation](https://goc8ycli.netlify.app/docs/introduction/). **Developer details** The CLI is a client application (go-c8y-cli) that makes authenticated calls to the public Cumulocity REST APIs, such as the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`), [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`)/application/applications`), and [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/users`). ### Cumulocity core {#core} Cumulocity Core is the foundation of the Cumulocity platform. It comprises all major components such as the default [applications](https://cumulocity.com/docs/glossary/#application) ([Administration](https://cumulocity.com/docs/glossary/#administration-application), [Cockpit](https://cumulocity.com/docs/glossary/#cockpit-application) and [Device Management](https://cumulocity.com/docs/glossary/#device-management-application)), the [Cumulocity operational store](https://cumulocity.com/docs/glossary/#operational-store), [microservices](https://cumulocity.com/docs/glossary/#microservice), security, [REST API](https://cumulocity.com/docs/glossary/#rest-api), MQTT API, and smart rules. **Developer details** Core functionalities are accessed via the main REST APIs (such as [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API), [Event API](https://cumulocity.com/api/core/#tag/Event-API), [Alarm API](https://cumulocity.com/api/core/#tag/Alarm-API), [Measurement API](https://cumulocity.com/api/core/#tag/Measurement-API)) documented in the [Cumulocity OpenAPI Specification](https://cumulocity.com/api/core/). ### Cumulocity DataHub {#datahub} Cumulocity Datahub is a Cumulocity [application](https://cumulocity.com/docs/glossary/#application) for periodically offloading data from the [Cumulocity operational store](https://cumulocity.com/docs/glossary/#operational-store) to a [data lake](https://cumulocity.com/docs/glossary/#data-lake) and querying the data lake contents. See also [DataHub](https://cumulocity.com/docs/datahub/datahub-overview/) in the documentation. **Developer details** DataHub provides a REST API (`/service/datahub/`) to proxy query-related requests to the Dremio engine. ### Cumulocity Web developer codex {#developer-codex} The [Cumulocity Web developer codex](https://cumulocity.com/codex/) is Cumulocity's comprehensive design system aimed at developers building custom [web applications](https://cumulocity.com/docs/glossary/#web-application). The Cumulocity Web developer codex provides a set of UI guidelines, a library of reusable Angular components ([Web SDK](https://cumulocity.com/docs/glossary/#web-sdk)), and styling utilities to ensure that custom [applications](https://cumulocity.com/docs/glossary/#application) maintain a consistent look and feel, and user experience with standard Cumulocity applications. ### Cumulocity Edge {#edge} Cumulocity Edge is the onsite solution of Cumulocity intended to run as a local software application on industrial PC’s or local servers. See also [Edge](https://cumulocity.com/docs/2026/edge) in the documentation. **Developer details** Core REST APIs (such as [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API), [Event API](https://cumulocity.com/api/core/#tag/Event-API), [Alarm API](https://cumulocity.com/api/core/#tag/Alarm-API), [Measurement API](https://cumulocity.com/api/core/#tag/Measurement-API)) are typically available locally on the Edge instance. ### Cumulocity Messaging Service {#messaging-service} The Cumulocity Messaging Service is a publish/subscribe messaging bus that provides decoupled, asynchronous data transfer between Cumulocity components, as well as to and from hosted microservices and external client applications. Amongst other things, it is used by the [data broker](https://cumulocity.com/docs/glossary/#data-broker), [Notifications 2.0](https://cumulocity.com/docs/notifications/), [Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics) and the [MQTT Service](https://cumulocity.com/docs/glossary/#mqtt-service). ### Cumulocity MQTT Service {#mqtt-service} The Cumulocity MQTT Service is a unified endpoint for all MQTT protocol traffic flowing in and out of the Cumulocity platform. It supports MQTT devices that implement the Cumulocity "core MQTT" protocols ([SmartREST](https://cumulocity.com/docs/glossary/#smartrest) and JSON-over-MQTT), and "generic" devices that implement non-Cumulocity protocols. See also [MQTT Service](https://cumulocity.com/docs/device-integration/mqtt-service/) in the documentation. **Developer details** Generic devices are integrated using a custom [microservice](https://cumulocity.com/docs/glossary/#microservice) or external client that implements a mapping between the device protocol and the Cumulocity [domain model](https://cumulocity.com/docs/glossary/#domain-model). Microservices and external clients interact with the MQTT Service through the [Messaging Service](https://cumulocity.com/docs/glossary/#messaging-service), using the Apache Pulsar publish/subscribe API. ### Cumulocity OpenAPI Specification {#openapi-specification} The Cumulocity OpenAPI Specification is a complete OpenAPI specification (following the OpenAPI 3.0 standard) for the Cumulocity [REST API](https://cumulocity.com/docs/glossary/#rest-api), available at [https://cumulocity.com/api/](https://cumulocity.com/api/). It describes the entire REST API, including available endpoints, operations on each endpoint, input and output for each operation, and authentication methods. ### Cumulocity operational store {#operational-store} The Cumulocity operational store is an internal datastore where all data (such as [alarms](https://cumulocity.com/docs/glossary/#alarm), [events](https://cumulocity.com/docs/glossary/#event), [inventory](https://cumulocity.com/docs/glossary/#inventory), and [measurements](https://cumulocity.com/docs/glossary/#measurement)) are stored in base collections. **Developer details** The operational store is accessed indirectly via the standard REST APIs for respective data types: `/alarm/alarms`, `/event/events`, `/inventory/managedObjects`, `/measurement/measurements`. Direct API access to the store is not provided. ### Cumulocity Sensor App {#sensor-app} The Cumulocity Sensor App is a free smartphone [application](https://cumulocity.com/docs/glossary/#application) for iOS and Android that turns a smartphone into a managed IoT [device](https://cumulocity.com/docs/glossary/#device), enabling the real-time collection of sensor data from the phone, connected Bluetooth devices, and supported OBD sensors. It securely transmits this data to the Cumulocity platform and supports device registration, live data visualization, [event](https://cumulocity.com/docs/glossary/#event) and [alarm](https://cumulocity.com/docs/glossary/#alarm) triggering, and remote device operations, providing an easy entry point for exploring Cumulocity’s IoT capabilities. See also [Cumulocity Sensor App](https://cumulocity.com/docs/sensor-app/sensorapp-introduction/) in the documentation. ### Cumulocity Streaming Analytics {#streaming-analytics} The Cumulocity Streaming Analytics application allows users to add their own logic for the immediate, real-time processing of incoming data. Users can build [Analytics Builder](https://cumulocity.com/docs/glossary/#analytics-builder) [models](https://cumulocity.com/docs/glossary/#model) or write custom [EPL Apps](https://cumulocity.com/docs/glossary/#epl-apps) to analyze data streams, generate new data, create [alarms](https://cumulocity.com/docs/glossary/#alarm), or trigger [operations](https://cumulocity.com/docs/glossary/#operation) on [devices](https://cumulocity.com/docs/glossary/#device). See also [Analytics > Streaming Analytics](https://cumulocity.com/docs/streaming-analytics/introduction-analytics/) in the documentation. **Developer details** Streaming Analytics is powered by the Apama analytics engine. The configuration uses tenant options as described in [Monitoring and configuration](https://cumulocity.com/docs/streaming-analytics/analytics-builder/#monitoring-and-configuration). Monitoring and diagnostics uses specific REST endpoints (`/service/cep/diagnostics`, `/service/cep/monitoring`) or Prometheus as described in [Troubleshooting and diagnostics](https://cumulocity.com/docs/streaming-analytics/troubleshooting/#monitoring-rest). ## D ### Dashboard {#dashboard} Dashboards are customizable views within [applications](https://cumulocity.com/docs/glossary/#application) like the [Cockpit application](https://cumulocity.com/docs/glossary/#cockpit-application), composed of various [widgets](https://cumulocity.com/docs/glossary/#widget), used to visualize data, monitor [assets](https://cumulocity.com/docs/glossary/#asset), and potentially trigger actions. See also [Working with dashboards](https://cumulocity.com/docs/cockpit/working-with-dashboards/) in the documentation. **Developer details** Dashboards are stored as managed objects in the Inventory, with a `c8y_Dashboard` fragment. Their configuration, including layout and widget settings, is stored as a complex JSON object within this managed object. Dashboards are created and updated via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`POST /inventory/managedObjects` and `PUT /inventory/managedObjects/{id}`). ### Data broker {#data-broker} The data broker functionality is an optional feature in Enterprise tenants which lets you share data selectively with other [tenants](https://cumulocity.com/docs/glossary/#tenant). See also [Data broker](https://cumulocity.com/docs/data-broker/) in the documentation. **Developer details** Configuration of broker connections is done using the Administration application. The underlying REST APIs are internal to the feature-broker application and are not part of the public API set. The messaging-based broker is used if the databroker-agent-server microservice is subscribed to the tenant. Otherwise, the original in-memory implementation is still used. ### Data explorer {#data-explorer} The data explorer is a visualization tool for exploring, comparing, and analyzing IoT data, such as [measurements](https://cumulocity.com/docs/glossary/#measurement), [alarms](https://cumulocity.com/docs/glossary/#alarm), and [events](https://cumulocity.com/docs/glossary/#event), from specific [assets](https://cumulocity.com/docs/glossary/#asset) or across all assets. See also [Data explorer](https://cumulocity.com/docs/cockpit/data-explorer/) in the documentation. **Developer details** The data explorer UI component uses the [Measurement API](https://cumulocity.com/api/core/#tag/Measurements ) (`/measurement/measurements` and `/measurement/measurements/series`) to fetch and visualize data. ### Data lake {#data-lake} Data lakes are used in the context of [Cumulocity DataHub](https://cumulocity.com/docs/glossary/#datahub). A data lake serves as a storage container for offloaded data, for example, ADLS Gen2/Azure Storage (Azure), S3 (Amazon), or a NAS. **Developer details** The data lake is an external storage which can only be accessed through the DataHub application and Dremio, and not via API. ### Data point {#data-point} A data point is a configuration that defines how a specific [measurement](https://cumulocity.com/docs/glossary/#measurement) time series is visualized in UI views like the [data explorer](https://cumulocity.com/docs/glossary/#data-explorer) and [dashboards](https://cumulocity.com/docs/glossary/#dashboard). Data points define how a measurement stream is displayed, including its label, color, unit, and threshold ranges. These settings can be customized in the UI or templated in the [data point library](https://cumulocity.com/docs/glossary/#data-point-library). **Developer details** A data point is a UI concept and has no direct API. The underlying data is retrieved via the [Measurement API](https://cumulocity.com/api/core/#tag/Measurements ) (`GET /measurement/measurements/series`). Visualization properties are stored within a dashboard's managed object configuration or in the data point library. ### Data point library {#data-point-library} The data point library provides a collection of templates used to standardize the visualization of measurement data across your account. Each template targets a specific [measurement](https://cumulocity.com/docs/glossary/#measurement), identified by its [fragment](https://cumulocity.com/docs/glossary/#fragment) and series, and defines its visual properties (such as label, color, unit, threshold ranges). This ensures that all matching time series from any [device](https://cumulocity.com/docs/glossary/#device) are displayed consistently. See also [Data point library](https://cumulocity.com/docs/cockpit/data-point-library/) in the documentation. **Developer details** The data point library is managed via the Cockpit UI. The entries are stored in the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) with a fragment called `c8y_Kpi`. ### Data Preparation {#data-preparation} Data Preparation is a Cumulocity component that processes inbound device messages before they enter the platform's operational store. It is used to decode device payloads from any transport, map them to Cumulocity domain objects, enrich or filter them, and send the result into the platform. Data Preparation is built around [Data Preparation rules](https://cumulocity.com/docs/glossary/#data-preparation-rule), each of which carries a [smart function](https://cumulocity.com/docs/glossary/#smart-function) that performs the actual processing. See also [Data Preparation](https://cumulocity.com/docs/data-preparation/) in the documentation. ### Data Preparation rule {#data-preparation-rule} A Data Preparation rule is a configurable pipeline that selects a subset of inbound device traffic and processes it through a [smart function](https://cumulocity.com/docs/glossary/#smart-function) to produce Cumulocity domain objects such as [measurements](https://cumulocity.com/docs/glossary/#measurement), [events](https://cumulocity.com/docs/glossary/#event), [alarms](https://cumulocity.com/docs/glossary/#alarm), or [operations](https://cumulocity.com/docs/glossary/#operation). Each rule comprises exactly one smart function, which performs all transformation, enrichment, and mapping. See also [Data Preparation](https://cumulocity.com/docs/data-preparation/) in the documentation. ### Device {#device} A device is a special type of [asset](https://cumulocity.com/docs/glossary/#asset) that represents a physical piece of equipment connected to the Cumulocity platform. Devices are distinct from other assets because they can send data and can receive remote operations. **Developer details** In the inventory, devices are represented as managed objects (/inventory/managedObjects), marked with the `c8y_IsDevice` fragment. The identity is managed via the [Identity API](https://cumulocity.com/api/core/#tag/Identity-API) (`/identity/externalIds`), operations via the [Device Control API](https://cumulocity.com/api/core/#tag/Device-control-API) (`/devicecontrol/operations`), and data sent/received via the [Measurement API](https://cumulocity.com/api/core/#tag/Measurements) (`/measurement/measurements`), [Event API](https://cumulocity.com/api/core/#tag/Events), and [Alarm API](https://cumulocity.com/api/core/#tag/Alarms). ### Device agent {#device-agent} Device agents are software components that translate a device-specific communication [protocol](https://cumulocity.com/docs/glossary/#device-protocol) into the standard Cumulocity REST or MQTT-based protocol, enabling secure, bi-directional communication. Device agents can be deployed on the [device](https://cumulocity.com/docs/glossary/#device) itself (for example, on a gateway) or run as server-side [microservices](https://cumulocity.com/docs/glossary/#microservice) within the Cumulocity platform. **Developer details** In the inventory, agents are represented as managed object, marked with the `com_cumulocity_model_Agent` fragment (`/inventory/managedObjects`). They interact heavily with the Device Control API (`/devicecontrol/operations`) to receive and update operations for themselves and their child devices, often using real-time notifications (`/cep/realtime`). ### Device Management application {#device-management-application} The Device Management application is one of the default [applications](https://cumulocity.com/docs/glossary/#application) of Cumulocity. It provides functionalities for connecting, managing and monitoring [devices](https://cumulocity.com/docs/glossary/#device) and allows to control and troubleshoot devices remotely. See also [Device Management application](https://cumulocity.com/docs/device-management-application/) in the documentation. **Developer details** The Device Management UI utilizes core REST APIs: [Inventory](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`), [Identity](https://cumulocity.com/api/core/#tag/Identity-API) (`/identity/externalIds`), [Device Control](https://cumulocity.com/api/core/#tag/Device-control-API) (`/devicecontrol/operations`), and data APIs (Measurement/Event/Alarm). ### Device protocol {#device-protocol} A device protocol defines how data from a specific device type is transferred into the Cumulocity platform and translated into the Cumulocity data model. **Developer details** Standard protocols (REST, MQTT) follow documented patterns. Custom protocols may involve creating specific managed objects via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) or dedicated microservice APIs. ### Device replacement {#device-replacement} The device replacement feature allows the replacement of physical devices without losing the historical data associated with the original [device](https://cumulocity.com/docs/glossary/#device). **Developer details** The device replacement process is centered around the [Identity API](https://cumulocity.com/api/core/#tag/Identity-API) (`/identity/externalIds`). It involves re-mapping the external identifiers from the old device to the new one while keeping the same managed object ID in the inventory. ### Device topic {#device-topic} A device topic is a [topic](https://cumulocity.com/docs/glossary/#topic) used by a device connected to a [protocol adapter](https://cumulocity.com/docs/glossary/#protocol-adapter). Typically, the topic describes the type of data being sent and received by the device. For example, a metering device connected to the [MQTT Service](https://cumulocity.com/docs/glossary/#mqtt-service) publishes messages on topics `meters/123456/current` and `meters/123456/temperature`. The naming and meaning of device topics is specific to the device type, protocol, and the application using the devices. See [Core MQTT topics](https://cumulocity.com/docs/device-integration/mqtt-service/#core-mqtt-topics) for another example of a topic schema used by MQTT devices, in this case devices that use the [SmartREST](https://cumulocity.com/docs/glossary/#smartrest) device protocol. See the [MQTT protocol specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901241) for more information about MQTT topics. **Developer details** See [Connecting MQTT devices](https://cumulocity.com/docs/device-integration/mqtt-service/#connecting-devices) for more information about integrating devices with the MQTT Service. ### Digital twin {#digital-twin} A digital twin is a virtual representation of a physical asset or system that is continuously updated with real-time IoT data from connected [devices](https://cumulocity.com/docs/glossary/#device). This data-driven digital counterpart enables monitoring, analysis, and optimization of physical assets by combining sensor [measurements](https://cumulocity.com/docs/glossary/#measurement) with business context. ### Digital Twin Manager (DTM) {#dtm} The Digital Twin Manager (DTM) is a schema-based modeling [application](https://cumulocity.com/docs/glossary/#application) in Cumulocity that enables users to create and manage data model schemas, which serve as blueprints for modeling [assets](https://cumulocity.com/docs/glossary/#asset), [properties](https://cumulocity.com/docs/glossary/#asset-property), and other [managed objects](https://cumulocity.com/docs/glossary/#managed-object), acting as reusable templates within the platform. See also [Digital Twin Manager](https://cumulocity.com/docs/dtm/) in the documentation. **Developer details** The DTM application is supported by a dedicated Dtm microservice and a dedicated API (`/service/dtm/`) to manage the lifecycle of asset definitions, property definitions, and asset instances. ### Document {#document} Cumulocity stores all operational data, such as [managed objects](https://cumulocity.com/docs/glossary/#managed-object), [alarms](https://cumulocity.com/docs/glossary/#alarm), and [measurements](https://cumulocity.com/docs/glossary/#measurement), as documents. Documents are the fundamental JSON structures used in Cumulocity [REST APIs](https://cumulocity.com/docs/glossary/#rest-api). **Developer details** A document is a versatile JSON structure with a unique identifier, allowing it to be referenced in URLs of web applications or REST APIs. All major platform entities are represented as JSON documents manipulated via specific API endpoints. ### Domain model {#domain-model} The domain model is the conceptual framework that defines how Cumulocity structures, represents, and relates different types of information ([inventory](https://cumulocity.com/docs/glossary/#inventory), [measurements](https://cumulocity.com/docs/glossary/#measurement), [events](https://cumulocity.com/docs/glossary/#event), [operations](https://cumulocity.com/docs/glossary/#operation)). Data is organized as modular [fragments](https://cumulocity.com/docs/glossary/#fragment) within JSON documents, allowing flexible extension and customization. See also [Cumulocity's domain model](https://cumulocity.com/docs/concepts/domain-model/) in the documentation. **Developer details** The domain model is implemented and exposed through the core REST APIs ([Inventory](https://cumulocity.com/api/core/#tag/Inventory-API), [Measurement](https://cumulocity.com/api/core/#tag/Measurement-API), [Event](https://cumulocity.com/api/core/#tag/Event-API), [Alarm](https://cumulocity.com/api/core/#tag/Alarm-API)). Data is organized as modular fragments within JSON documents, allowing flexible extension and customization. ## E ### Edge Server {#edge-server} Edge Server is an informal term for Cumulocity Edge. See [Cumulocity Edge](https://cumulocity.com/docs/glossary/#edge). ### Enterprise tenant {#enterprise-tenant} An Enterprise tenant is a [tenant](https://cumulocity.com/docs/glossary/#tenant) type in the Cumulocity [tenant hierarchy](https://cumulocity.com/docs/glossary/#tenant-hierarchy) that provides advanced administrative capabilities, primarily focused on managing multiple [subtenants](https://cumulocity.com/docs/glossary/#subtenant). An Enterprise tenant (sometimes also referred as “parent” tenant) can create, manage, and bill its own subtenants and enables features like custom [branding](https://cumulocity.com/docs/glossary/#branding), custom domain names, and [user hierarchies](https://cumulocity.com/docs/glossary/#user-hierarchy). See also [Enterprise tenant administration](https://cumulocity.com/docs/enterprise-tenant/enterprise-tenant-introduction/) in the documentation. **Developer details** Enterprise tenants use specific administrative endpoints for detailed configuration such as a tenant domain or an email template. Subtenant management is performed via the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (`POST /tenant/tenants`). Application and branding subscriptions for subtenants are managed via `POST /tenant/tenants/{tenantId}/applications`. ### EPL (Event Processing Language) {#epl} [Apama](https://cumulocity.com/docs/glossary/#apama) EPL is a domain-specific, event-driven programming language with a syntax similar to Java, designed for writing programs that process [events](https://cumulocity.com/docs/glossary/#event) in realtime. In Cumulocity, EPL logic is typically implemented as [EPL apps](https://cumulocity.com/docs/glossary/#epl-apps) within the [Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics) application. ### EPL Apps {#epl-apps} EPL Apps is part of the [Cumulocity Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics) application. It allows you to develop a single-file EPL application directly within Cumulocity using [Apama](https://cumulocity.com/docs/glossary/#apama) [EPL](https://cumulocity.com/docs/glossary/#epl), giving you a pro-code environment to define your streaming analytics applications. **Developer details** EPL Apps are managed via the Streaming Analytics UI. The [Apama EPL Apps Tools GitHub repository](https://github.com/Cumulocity-IoT/apama-eplapps-tools) includes tools to help with testing and deploying EPL apps from the command line or a CI/CD environment. ### Event {#event} A Cumulocity event is a time-stamped informational record that transmits real-time information on any state change of a [device](https://cumulocity.com/docs/glossary/#device) or [asset](https://cumulocity.com/docs/glossary/#asset). Next to Cumulocity events, the following types of events are used within the Cumulocity platform: - In [Apama](https://cumulocity.com/docs/glossary/#apama) ([Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics)), an "event" is the fundamental data structure for all interactions. - [Alarms](https://cumulocity.com/docs/glossary/#alarm) are a special type of event. - [Audit logs](https://cumulocity.com/docs/glossary/#audit-log) are security-relevant events. **Developer details** Events are managed via the [Event API](https://cumulocity.com/api/core/#tag/Events) (`/event/events`). Key properties include type, time, text, and source. ### Export {#export} Export is a feature of the [Cockpit application](https://cumulocity.com/docs/glossary/#cockpit-application) that allows users to extract a limited amount of platform data, such as [measurements](https://cumulocity.com/docs/glossary/#measurement), [alarms](https://cumulocity.com/docs/glossary/#alarm), or [events](https://cumulocity.com/docs/glossary/#event), into CSV or XLSX files. Exports can be configured with filters for specific [devices](https://cumulocity.com/docs/glossary/#device), time ranges, and data fields. Recurring exports can be scheduled in the Cockpit application. See also [Exports](https://cumulocity.com/docs/cockpit/exports/) in the documentation. **Developer details** Export configurations are managed as a special type of managed object via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`). The object's JSON payload contains fragments defining the export parameters (filters, fields, file type) and schedule. The report-agent microservice reads these managed objects to execute scheduled exports. Manual exports triggered from the UI are also handled by this backend service, which sends the user an email with a download link. ### Extensions {#extensions} Extensions are official or community-supported packages that add new functionalities to the Cumulocity platform. They can include plugins, which add features to existing [applications](https://cumulocity.com/docs/glossary/#application) at runtime, or blueprints, which are combinations of preconfigured UI functionalities for creating new applications. For information about uploading extensions for Analytics Builder, see [Creating your own blocks](https://cumulocity.com/docs/streaming-analytics/analytics-builder/#creating-your-own-blocks). **Developer details** Individual extensions are bundled into a package which is installed as an application via the [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`/application/applications`) and contains an `isPackage` flag inside the manifest. Additionally, extensions use the [Versioning API](https://cumulocity.com/api/core/#tag/Application-versions), to ensure compatibility when they are integrated into an application. ## F ### Fragment {#fragment} Fragments are JSON objects used to extend Cumulocity's core data types, such as [managed objects](https://cumulocity.com/docs/glossary/#managed-object), [events](https://cumulocity.com/docs/glossary/#event), and [operations](https://cumulocity.com/docs/glossary/#operation). They are the primary mechanism for creating a flexible and extensible [domain model](https://cumulocity.com/docs/glossary/#domain-model), allowing the representation of any [asset](https://cumulocity.com/docs/glossary/#asset) or [device](https://cumulocity.com/docs/glossary/#device) without a rigid, predefined database schema. **Developer details** Fragments are embedded within other resources and are managed as part of their parent resource via the respective APIs (for example, updating a `c8y_Position` fragment via `PUT /inventory/managedObjects/{id}`). ### Fragment library {#fragment-library} The fragment library defines the data structures that are used in Cumulocity for device management activities like, for example, [configuration management](https://cumulocity.com/docs/glossary/#configuration-management). The data structures are expressed as [fragments](https://cumulocity.com/docs/glossary/#fragment) that can be used inside [managed objects](https://cumulocity.com/docs/glossary/#managed-object), [operations](https://cumulocity.com/docs/glossary/#operation) and other resources. See also [Fragment library](https://cumulocity.com/docs/device-integration/fragment-library/) in the documentation. **Developer details** The fragment library is a conceptual, documented library of standard JSON structures (fragments) that define the platform's data model for common device capabilities. It serves as a developer reference for building integrations using REST and SmartREST APIs. ## G ### General Availability (GA) {#ga} In the [Continuous Deployment model](https://cumulocity.com/docs/glossary/#continuous-deployment), General Availability (GA) refers to the availability of a feature to all customers (as compared to [Private Preview](https://cumulocity.com/docs/glossary/#private-preview) and [Public Preview](https://cumulocity.com/docs/glossary/#public-preview)). In the [Yearly release](https://cumulocity.com/docs/glossary/#yearly-release) model, General Availability (GA) refers to the general availability of a Yearly release. This is the stage where a feature is fully released and supported. ### Global role {#global-role} A type of [role](https://cumulocity.com/docs/glossary/#role) in Cumulocity's [permission](https://cumulocity.com/docs/glossary/#permission) model that contains permissions applying to all data within a [tenant](https://cumulocity.com/docs/glossary/#tenant). Unlike [inventory roles](https://cumulocity.com/docs/glossary/#inventory-role), which grant permissions to specific [assets](https://cumulocity.com/docs/glossary/#asset) or [groups](https://cumulocity.com/docs/glossary/#group), global roles apply tenant-wide. For details, see [Global roles](https://cumulocity.com/docs/standard-tenant/managing-permissions/#global-roles) in the documentation. **Developer details** Global roles are managed via the [User API](https://cumulocity.com/api/core/#tag/User-API). They are defined under `/user/roles` and can be assigned to users via `POST /user/users/{username}/roles`. ### Group {#group} A group is a special type of [asset](https://cumulocity.com/docs/glossary/#asset) used to organize [devices](https://cumulocity.com/docs/glossary/#device) and other assets for structural and [permission](https://cumulocity.com/docs/glossary/#permission)-management purposes. Groups support flexible organization and, when paired with [inventory roles](https://cumulocity.com/docs/glossary/#inventory-role), can grant or restrict [user](https://cumulocity.com/docs/glossary/#user) access to the contained devices and assets. **Developer details** In the inventory ([Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API)), groups are represented as managed objects (`/inventory/managedObjects`), using a `c8y_IsDeviceGroup` fragment and often with type `c8y_DeviceGroup`. Assets, devices or subgroups are assigned via child asset references (`POST /inventory/managedObjects/{groupId}/childAssets`). ## I ### Inventory {#inventory} The inventory stores all master data for [devices](https://cumulocity.com/docs/glossary/#device) and [assets](https://cumulocity.com/docs/glossary/#asset), including their configurations and relationships, and serves as the [digital twin](https://cumulocity.com/docs/glossary/#digital-twin) of physical or logical entities within Cumulocity. **Developer details** The inventory is managed via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`). It allows creating (POST), retrieving (GET), updating (PUT), and deleting (DELETE) managed objects. ### Inventory role {#inventory-role} Inventory [roles](https://cumulocity.com/docs/glossary/#role) contain [permissions](https://cumulocity.com/docs/glossary/#permission) that grant access to specific groups of [devices](https://cumulocity.com/docs/glossary/#device) or [assets](https://cumulocity.com/docs/glossary/#asset) in the [inventory](https://cumulocity.com/docs/glossary/#inventory). They allow fine-grained [authorization](https://cumulocity.com/docs/glossary/#authorization) to particular assets or device groups and their associated data. For details, see [Inventory roles](https://cumulocity.com/docs/standard-tenant/managing-permissions/#inventory-roles) in the documentation. **Developer details** Inventory roles are managed via the [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/inventoryroles`). They are assigned to users for specific managed object groups via `/user/users/{username}/inventoryroles`, linking the user ID, group ID, and inventory role ID. ### Isolation level {#isolation-level} The isolation level defines how [microservice](https://cumulocity.com/docs/glossary/#microservice) instances are shared among [tenants](https://cumulocity.com/docs/glossary/#tenant). Options are either "multi-tenant" (MULTI\_TENANT in the manifest), where a single instance serves multiple subscribed tenants, or "per-tenant" (PER\_TENANT in the manifest), where a dedicated instance is created for each subscribing tenant. **Developer details** The isolation level is a declarative setting configured in the *cumulocity.json* manifest file within the microservice package. ## L ### Location {#location} The location represents the geographical position of a [managed object](https://cumulocity.com/docs/glossary/#managed-object). The location is represented by the standard `c8y\_Position` [fragment](https://cumulocity.com/docs/glossary/#fragment), which contains altitude, longitude, and latitude coordinates. Managed objects with this fragment can be displayed on Map widgets. **Developer details** Location information is updated by sending an event of type `c8y_LocationUpdate` that contains a `c8y_Position fragment` (`POST /event/events`). Additionally, the `c8y_Position` fragment must be updated directly in the managed object (`PUT /inventory/managedObjects/{id}`). ## M ### Maintenance release {#maintenance-release} Maintenance releases are provided for supported [Yearly releases](https://cumulocity.com/docs/glossary/#yearly-release) and contain important bug fixes but no new features, ensuring stability and security for long-term supported versions of the platform. ### Managed object {#managed-object} Managed objects are the core building blocks of the Cumulocity [inventory](https://cumulocity.com/docs/glossary/#inventory). A managed object is the primary digital record ([digital twin](https://cumulocity.com/docs/glossary/#digital-twin)) used to represent entities such as [devices](https://cumulocity.com/docs/glossary/#device), [assets](https://cumulocity.com/docs/glossary/#asset), logical [groupings](https://cumulocity.com/docs/glossary/#group), or [application](https://cumulocity.com/docs/glossary/#application) components. Managed objects are used to model data sources (for example, an IoT sensor), and all related data, such as [events](https://cumulocity.com/docs/glossary/#event), [alarms](https://cumulocity.com/docs/glossary/#alarm), and [operations](https://cumulocity.com/docs/glossary/#operation), linked to the managed object. When referred to as a “source managed object”, it denotes the managed object representing the origin of that data. **Developer details** Managed objects are the core resource of the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`). A minimal managed object requires a name and can include a type and other fragments, for example, `{"name": "MySensor", "type": "temp_sensor", "c8y_IsDevice": {}}`. ### Management tenant {#management-tenant} The Management tenant builds the highest level in the Cumulocity 3-level [tenant hierarchy](https://cumulocity.com/docs/glossary/#tenant-hierarchy), typically only available to the Operations team managing the Cumulocity instance. The Management tenant administers the entire platform deployment, including all [Enterprise tenants](https://cumulocity.com/docs/glossary/#enterprise-tenant), and holds exclusive platform-level administrative capabilities. **Developer details** Access to the Management tenant's full administrative API is typically restricted. It uses the same core APIs as the Enterprise tenant (for example, `/tenant/tenants`) but with elevated, platform-wide permissions. ### Measurement {#measurement} A measurement is a time-stamped reading or statistic collected from a sensor or [device](https://cumulocity.com/docs/glossary/#device) and linked to a source [managed object](https://cumulocity.com/docs/glossary/#managed-object). Measurements are organized into one or more [fragments](https://cumulocity.com/docs/glossary/#fragment) (for example, `c8y_TemperatureMeasurement`), each containing one or more series (for example, `T`) that hold a numeric value and a unit for specific observed properties. **Developer details** Measurements are managed via the [Measurement API](https://cumulocity.com/api/core/#tag/Measurements ) (`/measurement/measurements`). They are created using POST and linked to a source managed object. The `X-Cumulocity-Processing-Mode` header can be used to create transient measurements. ### Messaging Service topic {#messaging-service-topic} A Messaging Service topic is a [topic](https://cumulocity.com/docs/glossary/#topic) used by the [Messaging Service](https://cumulocity.com/docs/glossary/#messaging-service) to pass messages between [protocol adapters](https://cumulocity.com/docs/glossary/#protocol-adapter), microservices, and internal Cumulocity components. The Messaging Service uses its own topic namespace, with specific topics used by each of the services supported by the Messaging Service. For example, all messages published by devices using the [MQTT Service](https://cumulocity.com/docs/glossary/#mqtt-service) are delivered to microservices on the `from-device` topic, regardless of the MQTT topic used. In this case, the MQTT topic will be passed as a metadata field on the message. Other protocol adapters follow the same convention for mapping their [device topics](https://cumulocity.com/docs/glossary/#device-topic) to Messaging Service topics. **Developer details** See [Integrating with microservice and external applications](https://cumulocity.com/docs/device-integration/mqtt-service/#pulsar-client) for more information about building microservices to work with devices connected to the MQTT Service. ### Microfrontend {#microfrontend} Microfrontend refers to an architectural style for [web applications](https://cumulocity.com/docs/glossary/#web-application) where the UI is decomposed into smaller, independently deployable [applications](https://cumulocity.com/docs/glossary/#application) or plugins. Cumulocity's web UI is built on this architecture with the [Web SDK](https://cumulocity.com/docs/glossary/#web-sdk), allowing a "shell" application (like [Cockpit](https://cumulocity.com/docs/glossary/#cockpit-application)) to be extended by loading "remote" modules (plugins) from other web applications. **Developer details** Microfrontends (plugins) are packaged as standard web applications and uploaded as ZIP archives via the [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`POST /application/applications/{id}/versions`). The *cumulocity.json* manifest must include `isPackage: true` and an exports section defining the available modules. Other applications can then import the microfrontend by referencing it in their application remotes section. ### Microservice {#microservice} Microservices are server-side [applications](https://cumulocity.com/docs/glossary/#application) that extend Cumulocity’s functionality, typically by implementing backend business logic or enabling integration with external systems. They are fully integrated into Cumulocity’s hosting, security, and API management, and can be designed to be highly available, scalable, and [multi-tenant](https://cumulocity.com/docs/glossary/#multi-tenancy). See also [Microservices](https://cumulocity.com/docs/microservice-sdk/) in the documentation. ### Microservice manifest {#microservice-manifest} A microservice manifest is a required JSON file (*cumulocity.json*) included within a [microservice](https://cumulocity.com/docs/glossary/#microservice) package. It provides the necessary metadata for the platform to manage the microservice's deployment, lifecycle, and integration. See also [Microservice manifest](https://cumulocity.com/docs/microservice-sdk/general-aspects/#microservice-manifest) in the documentation. **Developer details** The *cumulocity.json* manifest file is a static configuration file that is packaged within the microservice's ZIP archive and uploaded via `POST /application/applications/{id}/binaries`. ### Microservice SDK {#microservice-sdk} The Cumulocity Microservice SDK is a set of tools, libraries, and documentation that helps developers build custom [microservices](https://cumulocity.com/docs/glossary/#microservice) efficiently. For Java, Cumulocity provides a dedicated SDK with Spring Boot integration. The SDK streamlines development by offering built-in authentication against the platform and robust context management, enabling secure, [multi-tenant](https://cumulocity.com/docs/glossary/#multi-tenancy)-aware [applications](https://cumulocity.com/docs/glossary/#application). At the same time, microservices can be developed in any programming language, as long as they are packaged as Docker containers and comply with the platform’s requirements. **Developer details** The Microservice SDK is a collection of development tools. It provides client libraries that simplify interaction with the core Cumulocity REST APIs from within a microservice. ### Model (Analytics Builder) {#model} In [Analytics Builder](https://cumulocity.com/docs/glossary/#analytics-builder), a model is a visual representation of analytic logic created by connecting pre-built [blocks](https://cumulocity.com/docs/glossary/#block) via [wires](https://cumulocity.com/docs/glossary/#wire) in a drag-and-drop environment. Each block performs a specific function, and together they form a workflow that can transform, analyze, and act on incoming data. A model can be designed as a reusable template model, which uses placeholders instead of fixed values. When you provide specific values for these placeholders, you create a runnable model instance. **Developer details** See [Analytics Builder](https://cumulocity.com/docs/glossary/#analytics-builder). ### Multi-tenancy {#multi-tenancy} Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers ([tenants](https://cumulocity.com/docs/glossary/#tenant)). In Cumulocity, each tenant has a physically separated data space. Data sharing between tenants is disabled by default and must be explicitly configured (for example, using the [data broker](https://cumulocity.com/docs/glossary/#data-broker)). See also [Multi-tenancy](https://cumulocity.com/docs/concepts/tenant-hierarchy/#multi-tenancy) in the documentation. **Developer details** Multi-tenancy is an architectural feature, primarily managed by Enterprise tenants via the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (/tenant/tenants). ## N ### Navigator {#navigator} The navigator is an element on the left of the Cumulocity platform's UI. It provides a list of menu items that direct you to various pages within the [application](https://cumulocity.com/docs/glossary/#application) currently in use. **Developer details** The navigator is a UI component and does not have a direct REST API. It is extended using the Web SDK's `hookNavigator` provider to add new menu items (nodes). ### Notifications 2.0{#notifications-2.0} [Notifications 2.0](https://cumulocity.com/docs/notifications) allows applications or microservices to reliably process real-time notifications generated by Cumulocity. Notifications are published by the Cumulocity core and consumed by one or more microservices or external applications. Delivery of notifications to consumers is guaranteed provided no [service quotas](https://cumulocity.com/docs/service-terms/quotas/#realtime-apis) are exceeded. **Developer details** Notifications 2.0 uses the [Messaging Service](https://cumulocity.com/docs/glossary/#messaging-service) to decouple notification publishers from consumers. Users can create multiple [topics](https://cumulocity.com/docs/glossary/#messaging-service-topic) for the Cumulocity core to publish notifications onto. Each topic can have one or more consumers, each of which will receive all of the notifications on the topic in the same order. ## O ### Offloading pipeline {#offloading-pipeline} An offloading pipeline is a configurable job within [Cumulocity DataHub](https://cumulocity.com/docs/glossary/#datahub) that defines the process of extracting data from a specific collection in the [operational store](https://cumulocity.com/docs/glossary/#operational-store), transforming it, and loading it into a target table within a [data lake](https://cumulocity.com/docs/glossary/#data-lake). **Developer details** Offloading pipelines are configured and managed via the Cumulocity DataHub application UI. There is no public REST API for programmatically managing the pipeline configurations. ### Operation {#operation} Operations are instructions sent to a [device](https://cumulocity.com/docs/glossary/#device) or [asset](https://cumulocity.com/docs/glossary/#asset) to perform a specific action, such as control, configuration, or maintenance. Operations are linked to a source [managed object](https://cumulocity.com/docs/glossary/#managed-object), and are delivered asynchronously via Cumulocity’s reliable queuing mechanism. Devices execute operations and report results back, enabling consistent remote management and automation. Typical operations include installing a new firmware, switching a relay in a power meter or sending a credit to a vending machine. ### Owner {#owner} The [user](https://cumulocity.com/docs/glossary/#user) who creates an [inventory](https://cumulocity.com/docs/glossary/#inventory) object (such as a [device](https://cumulocity.com/docs/glossary/#device) or a [group](https://cumulocity.com/docs/glossary/#group)) automatically becomes its owner. Ownership grants users full [permission](https://cumulocity.com/docs/glossary/#permission) (ADMIN, READ, CHANGE) for that specific object to ensure that they can fully manage the resources they create. **Developer details** Ownership is an implicit permission model enforced by the platform's core APIs. When a user creates an object via `POST /inventory/managedObjects`, the owner field of the new object is automatically set to that user's ID. ## P ### Permission {#permission} Permissions are the most granular level of access control in Cumulocity, defining the access rights (for example, READ, CREATE, ADMIN) for a specific capability (for example, [alarms](https://cumulocity.com/docs/glossary/#alarm), [inventory](https://cumulocity.com/docs/glossary/#inventory)). Permissions are not assigned to [users](https://cumulocity.com/docs/glossary/#user) directly. Instead, they are grouped into [roles](https://cumulocity.com/docs/glossary/#role). See also [Managing permissions and roles](https://cumulocity.com/docs/standard-tenant/managing-permissions/) in the documentation. **Developer details** Permissions are granted via roles, which are managed through the [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/roles`, `/user/inventoryroles)`. The platform identifies each granular permission with a unique “permission” string, which is prefixed with ROLE_ (for example, ROLE_ALARM_READ). To grant a permission to a user, assign the required permission strings, such as ROLE_ALARM_READ, to a suitable global role or inventory role, then assign that role to the users who should have the respective permission. **Important**: The permission strings are frequently referred to as "roles" throughout the API and in the configuration files (for example, the microservice manifest includes a requiredRoles field) although they actually refer to a permission. ### Private Preview {#private-preview} Private Preview denotes a feature release stage in the [Continuous Deployment model](https://cumulocity.com/docs/glossary/#continuous-deployment) where a new feature is made available to a limited, invitation-only group of selected customers for feedback and testing, as opposed to [Public Preview](https://cumulocity.com/docs/glossary/#public-preview) and [General Availability](https://cumulocity.com/docs/glossary/#ga). See also [Preview features](https://cumulocity.com/docs/service-terms/previews/) in the documentation. ### Processing mode {#processing-mode} The processing mode is a mechanism that allows clients to control how Cumulocity handles incoming data ([measurements](https://cumulocity.com/docs/glossary/#measurement) and [events](https://cumulocity.com/docs/glossary/#event)) with respect to data persistence and real-time processing. Modes include: PERSISTENT (default), TRANSIENT (process, don't store), QUIESCENT (store, suppress notifications), and CEP (process transiently, suppress notifications). **Developer details** For REST, the processing mode is specified using the `X-Cumulocity-Processing-Mode` HTTP header. For MQTT, specific topics are used (s/, t/, q/, c/) to specify the processing mode. ### Protocol adapter {#protocol-adapter} A protocol adapter is a service that allows devices using a specific protocol to connect to the Cumulocity platform. An adapter is *payload-agnostic*, meaning that it manages the communication with the devices and routes payloads to and from the [Messaging Service](https://cumulocity.com/docs/glossary/#messaging-service) without translating between the device message format and the Cumulocity domain model. Contrast this with a [device agent](https://cumulocity.com/docs/glossary/#device-agent) that actively translates device messages to and from the Cumulocity domain model. The [MQTT Service](https://cumulocity.com/docs/glossary/#mqtt-service) is a good example of a protocol adapter. It allows *any* device that uses the MQTT protocol to connect, but a separate microservice must implement the mapping to Cumulocity measurements, alarms, events and other data types. ### Public Preview {#public-preview} Public Preview denotes a feature release stage in the [Continuous Deployment model](https://cumulocity.com/docs/glossary/#continuous-deployment) where a new feature is made available to any customer who opts in to use it. Features in this stage are not yet considered generally available as opposed to [Private Preview](https://cumulocity.com/docs/glossary/#private-preview) and [General Availability](https://cumulocity.com/docs/glossary/#ga). See also [Preview features](https://cumulocity.com/docs/service-terms/previews/) in the documentation. ## R ### RBAC (Role-Based Access Control){#rbac} RBAC (Role-Based Access Control) is a security model used by Cumulocity in which [permissions](https://cumulocity.com/docs/glossary/#permission) are grouped into [roles](https://cumulocity.com/docs/glossary/#role), and these roles are then assigned to [users](https://cumulocity.com/docs/glossary/#user) or user groups. This allows administrators to manage access based on a user's function or responsibilities. **Developer details** The RBAC model is implemented and managed through the [User API](https://cumulocity.com/api/core/#tag/User-API). Endpoints under `/user/roles` and `/user/inventoryroles` are used to define roles, while endpoints like `/user/users/{username}/roles` assign them to users. ### Release notes {#release-notes} Release notes are published for each Cumulocity [Yearly release](https://cumulocity.com/docs/glossary/#yearly-release) and its subsequent [maintenance releases](https://cumulocity.com/docs/glossary/#maintenance-release), detailing new features, bug fixes, and API changes. Release notes help users track changes and understand their impact on deployments. ### Report {#report} Reports are global [dashboards](https://cumulocity.com/docs/glossary/#dashboard), accessible in the [Cockpit application](https://cumulocity.com/docs/glossary/#cockpit-application), and visible across the entire [tenant](https://cumulocity.com/docs/glossary/#tenant) regardless of the [asset hierarchy](https://cumulocity.com/docs/glossary/#asset-hierarchy). A report serves as a customizable container for [widgets](https://cumulocity.com/docs/glossary/#widget) to visualize and track tenant-wide data like [applications](https://cumulocity.com/docs/glossary/#application), [alarms](https://cumulocity.com/docs/glossary/#alarm), and [assets](https://cumulocity.com/docs/glossary/#asset). See also [Working with reports](https://cumulocity.com/docs/cockpit/working-with-reports/) in the documentation. **Developer details** Reports are managed as managed objects via the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) (`/inventory/managedObjects`). They are basically a special type of dashboard. ### REST API {#rest-api} The Cumulocity REST API is an interface that allows for communication between the Cumulocity platform and other systems via HTTP and REST. For technical details on the available endpoints, see the [Cumulocity OpenAPI Specification](https://cumulocity.com/api/core/). ### Role {#role} Roles are named collections of [permissions](https://cumulocity.com/docs/glossary/#permission) that can be assigned to [users](https://cumulocity.com/docs/glossary/#user) and/or [devices](https://cumulocity.com/docs/glossary/#device) to determine the level of authorization on the platform. Roles are the central component of Cumulocity's [RBAC](https://cumulocity.com/docs/glossary/#rbac) model. The platform distinguishes between [global roles](https://cumulocity.com/docs/glossary/#global-role) (tenant-wide) and [inventory roles](https://cumulocity.com/docs/glossary/#inventory-role) (specific to the device data in the [inventory](https://cumulocity.com/docs/glossary/#inventory)). See also [Managing permissions and roles](https://cumulocity.com/docs/standard-tenant/managing-permissions/) in the documentation. **Developer details** Roles are managed via the [User API](https://cumulocity.com/api/core/#tag/User-API). Global roles are managed via `/user/roles`, while inventory roles are managed via `/user/inventoryroles`. **Important**: The platform identifies each granular permission with a unique “permission” string, which is prefixed with ROLE_ (for example, ROLE_ALARM_READ, ROLE_INVENTORY_ADMIN). This permission strings are frequently referred to as "roles" throughout the API and in the configuration files although they actually refer to a permission. ## S ### Service user {#service-user} A service user is a non-human user account that is created automatically when a [tenant](https://cumulocity.com/docs/glossary/#tenant) subscribes to a [microservice](https://cumulocity.com/docs/glossary/#microservice). It allows the microservice to interact with the tenant's data via the [REST API](https://cumulocity.com/docs/glossary/#rest-api) for background tasks, independent of any end-user's session. **Developer details** A microservice retrieves the credentials for its service user by making an authenticated GET request to `/application/currentApplication/subscriptions` using its bootstrap credentials. To obtain the service user, a service bootstrap user must be used. The service bootstrap user is provisioned to the microservice in its [microservice runtime](https://cumulocity.com/docs/microservice-sdk/general-aspects/#microservice-runtime) environment variables. ### Smart function {#smart-function} A smart function is user-supplied Javascript code embedded directly into a Cumulocity component to extend its behavior. Smart functions are more powerful and flexible than static configuration, but much simpler than building a [microservice](https://cumulocity.com/docs/glossary/#microservice) --- there is no container to build, no infrastructure to manage, and no separate deployment pipeline. They run in a secure, isolated environment with platform-enforced resource limits, and are used across components such as [Data Preparation](https://cumulocity.com/docs/glossary/#data-preparation) to process data, transform messages, build analytics, or customize behavior. See also [Smart functions](https://cumulocity.com/docs/concepts/smart-function-concept/) in the documentation. ### Smart group {#smart-group} Smart groups are [groups](https://cumulocity.com/docs/glossary/#group) whose membership is dynamically determined based on [device](https://cumulocity.com/docs/glossary/#device) properties matching defined criteria, rather than static assignment. This is a feature of the [Device Management application](https://cumulocity.com/docs/glossary/#device-management-application). See also [Using smart groups](https://cumulocity.com/docs/device-management-application/grouping-devices/#using-smart-groups) in the documentation. **Developer details** A smart group is a standard managed object of type `c8y_DeviceGroup` containing a `c8y_DynamicGroup` fragment that stores a filter query. To get the set of devices contained in this smart group at any given time, the filter query must be executed on the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API). ### SmartREST {#smartrest} SmartREST is a lightweight, CSV-based [device protocol](https://cumulocity.com/docs/glossary/#device-protocol) to exchange data between [devices](https://cumulocity.com/docs/glossary/#device) and the platform. SmartREST uses standard MQTT. The protocol enables devices to send and receive structured messages using templates that map message fields to object properties, reducing the message size and simplifying the integration for resource-constrained IoT devices. **Developer details** Devices communicate dedicated MQTT topics with Cumulocity. Each row of CSV data begins with a message ID that corresponds to either a specific, pre-registered request template or an extensive suite of built-in templates. ### Smart rules {#smart-rules} With smart rules, you can analyze real-time data and perform actions based on predefined conditions without writing any code. For example, you can create a rule to send an email or generate an [alarm](https://cumulocity.com/docs/glossary/#alarm) when a [measurement](https://cumulocity.com/docs/glossary/#measurement) exceeds a specific threshold. The platform provides two versions of this feature: - Smart rules collection: Provides a fixed set of rule templates, configured using a simple wizard in the [Cockpit application](https://cumulocity.com/docs/glossary/#cockpit-application). - Smart rules (NEW) plugin: Provides extendable and fully customizable rule templates. These are built using [Analytics Builder](https://cumulocity.com/docs/glossary/#analytics-builder) and then made available as simple forms in any application (such as [Cockpit](https://cumulocity.com/docs/glossary/#cockpit-application) and [Device Management](https://cumulocity.com/docs/glossary/#device-management-application)). See also [Smart rules collection](https://cumulocity.com/docs/cockpit/smart-rules-collection/) or [Smart rules (NEW) plugin](https://cumulocity.com/docs/cockpit/cockpit-smart-rules-plugin/) in the documentation. **Developer details** Rules are configured by applications that have the smart rules (NEW) plugin installed such as Cockpit or Device Management. Smart rules are powered by the Apama engine for Smart rules (NEW) and the “smartrule” microservice for the previous generation of smart rules. ### Standard tenant {#standard-tenant} A standard tenant is a [tenant](https://cumulocity.com/docs/glossary/#tenant) that does not have tenant management capabilities. Unlike an [Enterprise tenant](https://cumulocity.com/docs/glossary/#enterprise-tenant) or [Management tenant](https://cumulocity.com/docs/glossary/#management-tenant), a Standard tenant lacks [multi-tenancy](https://cumulocity.com/docs/glossary/#multi-tenancy) features and cannot create [subtenants](https://cumulocity.com/docs/glossary/#subtenant). See also [Standard tenant administration](https://cumulocity.com/docs/standard-tenant/standard-tenant-introduction/) in the documentation. **Developer details** The Standard tenant uses core REST APIs but lacks access to multi-tenant administrative APIs available to Enterprise tenants and Management tenants. ### Subscription In Cumulocity, a subscription denotes the process by which a [tenant](https://cumulocity.com/docs/glossary/#tenant) is granted access to an [web application](https://cumulocity.com/docs/glossary/#web-application) from the [Administration application](https://cumulocity.com/docs/glossary/#administration-application). A superior tenant (like an [Enterprise tenant](https://cumulocity.com/docs/glossary/#enterprise-tenant) or the [Management tenant](https://cumulocity.com/docs/glossary/#management-tenant))) subscribes [applications](https://cumulocity.com/docs/glossary/#application) and [microservices](https://cumulocity.com/docs/glossary/#microservice) to its subtenants. - For microservices: Subscription is a mandatory step. A microservice must be subscribed to a tenant to become available. - For web applications: Subscription makes a shared or marketplace application (like the [Cockpit application](https://cumulocity.com/docs/glossary/#cockpit-application)) available to a specific tenant. See also [Subscribing applications](https://cumulocity.com/docs/enterprise-tenant/managing-tenants/#subscribing-applications) in the documentation. **Developer details** Subscriptions are managed via the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (`POST /tenant/tenants/{tenantId}/applications`) and the [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`POST /application/applications/{applicationId}/subscription`). Microservices use `GET /application/currentApplication/subscriptions` to list subscribed tenants. ### Subtenant {#subtenant} A subtenant is a [tenant](https://cumulocity.com/docs/glossary/#tenant) created and managed under a parent tenant (either an [Enterprise tenant](https://cumulocity.com/docs/glossary/#enterprise-tenant) or the [Management tenant](https://cumulocity.com/docs/glossary/#management-tenant)) within the Cumulocity [tenant hierarchy](https://cumulocity.com/docs/glossary/#tenant-hierarchy). **Developer details** Subtenants are created and managed via the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (`/tenant/tenants`) by an administrator of a parent Enterprise tenant or Management tenant. ## T ### Tenant {#tenant} A tenant represents a logically isolated data space within Cumulocity, typically corresponding to a customer or organizational unit. It has its own [users](https://cumulocity.com/docs/glossary/#user), [devices](https://cumulocity.com/docs/glossary/#device), [applications](https://cumulocity.com/docs/glossary/#application), and data (see [Cumulocity's domain model](https://cumulocity.com/docs/concepts/domain-model/)). **Developer details** Tenants are managed via the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (`/tenant/tenants`). This includes creating subtenants (POST), retrieving details (GET), updating properties (PUT), and deleting (DELETE). Tenant-specific configurations are managed via the [Tenant Options API](https://cumulocity.com/api/core/#tag/Options) (`/tenant/options`). ### Tenant domain {#tenant-domain} The tenant domain refers to the domain name used to access a Cumulocity [tenant](https://cumulocity.com/docs/glossary/#tenant), in the format `.\`. It is used for login and API access and is distinct from the tenant’s unique identifier ([tenant ID](https://cumulocity.com/docs/glossary/#tenant-id)). For example, a tenant named "acme" on the instance cumulocity.com would have the tenant domain "acme.cumulocity.com". [Enterprise tenants](https://cumulocity.com/docs/glossary/#enterprise-tenant) and their [subtenants](https://cumulocity.com/docs/glossary/#subtenant) can optionally configure custom domains for access using the platform’s custom domain feature. **Developer details** The tenant domain is configured via the Administration application and requires subscribing to the Sslmanagement microservice. ### Tenant hierarchy {#tenant-hierarchy} The tenant hierachy refers to the structure organizing [tenants](https://cumulocity.com/docs/glossary/#tenant) in Cumulocity, involving a [Management tenant](https://cumulocity.com/docs/glossary/#management-tenant) at the top, [Enterprise tenants](https://cumulocity.com/docs/glossary/#enterprise-tenant) below it, and [Standard tenants](https://cumulocity.com/docs/glossary/#standard-tenant) at the lowest level. See also [Tenant hierarchy](https://cumulocity.com/docs/concepts/tenant-hierarchy/) in the documentation. **Developer details** Tenant hierarchies are managed through the [Tenant API](https://cumulocity.com/api/core/#tag/Tenant-API) (`/tenant/tenants`). Creating a subtenant (POST `/tenant/tenants`) under a parent tenant establishes the hierarchical link. ### Tenant ID {#tenant-id} A tenant ID is a unique identifier assigned to each [tenant](https://cumulocity.com/docs/glossary/#tenant). The tenant ID is often used as a prefix in the username for authentication (for example, `\/\`). ### Tenant option {#tenant-option} Tenant options are configurable key-value pairs associated with a [tenant](https://cumulocity.com/docs/glossary/#tenant), used to customize platform behavior, [application](https://cumulocity.com/docs/glossary/#application) settings, or store tenant-specific configurations. **Developer details** Tenant options are managed via the [Tenant Options API](https://cumulocity.com/api/core/#tag/Options) (`/tenant/options`). Options can be created (POST), retrieved (GET), updated (PUT), and deleted (DELETE). There is a mechanism to [encrypt](https://cumulocity.com/docs/microservice-sdk/general-aspects/#encryption) tenant options. If a tenant option is created with a key name that starts with `credentials.`, it is automatically encrypted. When the option is retrieved from a microservice, the `credentials.` prefix is removed, and the value is decrypted only if the microservice is the owner of the option. ### Tenant policy {#tenant-policy} Tenant policies are predefined sets of [tenant options](https://cumulocity.com/docs/glossary/#tenant-option) and retention rules that can be created in a [Management tenant](https://cumulocity.com/docs/glossary/#management-tenant) or [Enterprise tenant](https://cumulocity.com/docs/glossary/#enterprise-tenant) and applied when creating new [subtenants](https://cumulocity.com/docs/glossary/#subtenant) to ensure consistent initial configurations. Tenant policies are created and managed in the [Administration application](https://cumulocity.com/docs/glossary/#administration-application). See also [Tenant policies](https://cumulocity.com/docs/enterprise-tenant/managing-tenants/#tenant-policies) in the documentation. **Developer details** Tenant policies are stored in the inventory and managed through the [Inventory API](https://cumulocity.com/api/core/#tag/Inventory-API) endpoints (`/inventory/managedObjects`). When creating or updating a policy the request body must follow a specific format, for example, must contain the `c8y_TenantPolicy` fragment. ### Tech Community {#tech-community} The official online forum and knowledge base for Cumulocity users and developers to ask questions, share solutions, find tutorials, and stay updated on platform news and events. See [https://community.cumulocity.com/](https://community.cumulocity.com/). ### Thick Edge {#thick-edge} Thick Edge is an informal term for Cumulocity Edge, see [Cumulocity Edge](https://cumulocity.com/docs/glossary/#edge). ### thin-edge.io {#thin-edge} [thin-edge.io](https://thin-edge.io/) is an open-source software framework recommended by Cumulocity for custom device integration. It provides components and tools to connect [devices](https://cumulocity.com/docs/glossary/#device) to the platform, particularly suitable for implementing device-side logic. **Developer details** thin-edge.io exposes a local Cumulocity proxy endpoint to give device components access to the full Cumulocity REST API. ### Topic {#topic} A topic is a channel for messages sent by one or more _publishers_ and received by one or more _subscribers_. Messages are delivered in the same order they were published, and will be reliably delivered to all subscribers. In Cumulocity, a topic can refer to a [device topic](https://cumulocity.com/docs/glossary/#device-topic) or a [Messaging Service topic](https://cumulocity.com/docs/glossary/#messaging-service-topic). ## U ### User {#user} An individual account within a Cumulocity [tenant](https://cumulocity.com/docs/glossary/#tenant), identified by a unique username. Users are assigned [roles](https://cumulocity.com/docs/glossary/#role) with specific [permissions](https://cumulocity.com/docs/glossary/#permission) that determine their access rights to data and functionalities. **Developer details** Users are managed via the [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/users`). This includes creating (POST), retrieving (GET), updating (PUT), and deleting (DELETE) users. Role assignments are managed via sub-resources like `/user/users/{username}/roles`. ### User hierarchy {#user-hierarchy} An optional feature allowing the creation of hierarchical relationships between [users](https://cumulocity.com/docs/glossary/#user). This enables parent users to manage their sub-users and delegate [permissions](https://cumulocity.com/docs/glossary/#permission). **Developer details** User hierarchies are managed via the [User API](https://cumulocity.com/api/core/#tag/User-API) (`/user/users`). Creating/updating a user with an owner property establishes the hierarchy. ## W ### Web application {#web-application} A Cumulocity web application is a browser-based [application](https://cumulocity.com/docs/glossary/#application) hosted on the Cumulocity platform. This includes the official Cumulocity applications (such as [Cockpit](https://cumulocity.com/docs/glossary/#cockpit-application), [Device Management](https://cumulocity.com/docs/glossary/#device-management-application), [Administration](https://cumulocity.com/docs/glossary/#administration-application), and [Streaming Analytics](https://cumulocity.com/docs/glossary/#streaming-analytics)), as well as custom applications built by customers, optionally using the [Cumulocity Web SDK](https://cumulocity.com/docs/glossary/#web-sdk). **Developer details** Web applications are managed via the [Application API](https://cumulocity.com/api/core/#tag/Application-API) (`/application/applications`) with type: HOSTED. They are uploaded as ZIP archives containing at least an *index.html* file and optionally a *cumulocity.json* file. ### Web SDK {#web-sdk} The Cumulocity Web SDK is a development framework that enables users to build extensions or [web applications](https://cumulocity.com/docs/glossary/#web-application) for deployment on the Cumulocity platform. It provides secure API access, access to default UI components, and support for custom [branding](https://cumulocity.com/docs/glossary/#branding), allowing developers to create tailored [applications](https://cumulocity.com/docs/glossary/#application) that seamlessly integrate with the platform's ecosystem and maintain a consistent user experience. See also the [Cumulocity Web developer codex](https://cumulocity.com/docs/glossary/#developer-codex). **Developer details** The Web SDK is a development toolkit (primarily Angular-based, `@c8y/ngx-components`, `@c8y/client`) for building web applications. It is not an API itself but enables API usage from frontend applications. All packages can be found on npm in the @c8y scope. ### Widget {#widget} A widget is a configurable UI component that can be added to a Cumulocity [dashboard](https://cumulocity.com/docs/glossary/#dashboard) to visualize IoT data. Widgets can display maps, images, graphs, tables, and other information such as [alarms](https://cumulocity.com/docs/glossary/#alarm), [measurements](https://cumulocity.com/docs/glossary/#measurement), and [events](https://cumulocity.com/docs/glossary/#event). **Developer details** Widgets are UI components configured within a dashboard's managed object. The configuration for each widget is stored as a JSON object within the dashboard's data. Custom widgets are developed using the Web SDK. There is no dedicated API for widgets. ### Wire (Analytics Builder) {#wire} In [Analytics Builder](https://cumulocity.com/docs/glossary/#analytics-builder), wires are used to connect two or more [blocks](https://cumulocity.com/docs/glossary/#block) with each other for data transfer between the output port of one block and the input port of another block. ## Y ### Yearly release {#yearly-release} Yearly releases are provided in a yearly cycle and named after the year, for example, Cumulocity 2025 release. The [General Availability (GA)](https://cumulocity.com/docs/glossary/#ga) for a Yearly release is scheduled for the 31st of March of the respective year. See also, [Continous Deployment model](https://cumulocity.com/docs/glossary/#continuous-deployment).