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 by managing users, roles, and permissions, subscribing to and managing applications and microservices, and configuring tenant-level settings such as retention rules, custom properties, and branding.
See also Platform administration in the documentation.
/user/...) for users/roles, Tenant API (/tenant/...) for tenant settings/options, and 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 (/tenant/options).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 in the documentation.
/alarm/alarms/{alarmId}. SmartREST templates (for example, 301-304) simplify creation over MQTT/HTTP.Analytics Builder is a tool in the Cumulocity Streaming Analytics application for designing real-time analytics models in a graphical, drag-and-drop environment. By combining pre-built blocks, you can quickly build models to transform streaming IoT data, generate new data, create alerts, or trigger device operations.
See also Analytics Builder in the documentation.
Apama is the high-performance event processing engine that powers Cumulocity Streaming Analytics. It enables real-time analytics, forming the foundation for smart rules, Analytics Builder´s drag-and-drop models as well as custom EPL apps.
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. Diagnostics and monitoring are available via dedicated endpoints like /service/cep/diagnostics or using Prometheus as described in Troubleshooting and diagnostics.An application is a component integrated with the platform that delivers user interfaces (= web application), business logic (= 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 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 in the documentation.
/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 defines how a custom application or microservice can be shared and accessed. A superior tenant (that is, an Enterprise tenant or the Management tenant)) manages this availability to share applications with its subtenants.
The application switcher is a UI component that shows all Cumulocity applications the user has access to and allows switching between these applications.
GET /application/applications?user={userId}. The application manifest property noAppSwitcher (managed via the Application API) can be used to hide an application from the switcher.An asset is the digital representation of a business object within the Cumulocity inventory, such as a machine, building, or vehicle. Technically, an asset is a managed object that can be structured into a logical hierarchy (the asset hierarchy) using child asset relationships. Assets can take several forms: simple groups used for organization, devices that send telemetry data, or complex custom assets defined by an asset model in the Digital Twin Manager (DTM).
See also Digital Twin Manager in the documentation.
/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 model.An asset hierarchy is a structure within the inventory that organizes assets (based on asset models) and devices 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). It is fundamentally distinct from the communication hierarchy, which models the physical network topology (child devices).
See also Asset hierarchy in the documentation.
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-ms/...) for managing the underlying asset models and properties.An asset model is a reusable blueprint defined in the Digital Twin Manager (DTM) that specifies the structure, properties, and relationships of a particular type of asset. It includes a unique key and label, asset properties, and optionally references to child asset models to support the composition of asset hierarchies (for example, a wind turbine model composed of rotor and tower sub-models). Once published, an asset model governs how assets of that type are created, validated, and visualized across Cumulocity applications.
See also Asset models in the documentation.
/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.Asset properties are configurable attributes within an asset model that define, describe, and enrich an asset´s 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. Properties 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.
An audit log is a record of a security-relevant action performed on the platform. Audit logs are a special type of event that includes details about who performed an action (can be a human user, a device, a microservice or the platform itself), the application used, the activity itself, and the severity. They provide a chronological and immutable trail of operations for security analysis and compliance auditing.
See also Audit logs in the documentation.
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 is the process of verifying the identity of a user, device, or 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 in the documentation.
PUT /tenant/loginOptions (CREATE) and POST /tenant/loginOptions/{typeOrId}) (UPDATE).Authorization is the process of determining whether an authenticated identity (user, device, or application) has the necessary permissions to access a specific resource or perform a particular action. Authorization in Cumulocity is managed through a Role-Based Access Control (RBAC) model, in which permissions are bundled into global roles and inventory role.
/user/roles, /user/inventoryroles).Availability refers to the monitoring of the connection status of a 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.
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.Blocks are the basic processing units of an Analytics Builder 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 comes with a set of prebuilt blocks.
Branding is a feature, typically available in Enterprise tenants 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.
Bulk device registration is a method for registering larger quantities of devices into the Cumulocity platform by uploading a CSV file containing device details, rather than registering each device individually.
CCU (Cumulocity Compute Unit) is a standardized measure for computational resources consumed by custom microservices 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 and the subscribed time for each microservice.
Change logs are the official record of Cumulocity product changes and announcements, published for all cloud deployments (Continous Deployment), detailing updates such as new features, improvements, and API changes or deprecations. Corresponds to the release notes in the Yearly releases.
See Change logs.
Child assets denote a relationship type within the Cumulocity inventory’s domain model used to establish parent-child links between managed objects. This relationship forms the asset hierarchy, connecting a parent asset or group to its subordinate assets or devices from a business or logical perspective.
GET /inventory/managedObjects/{id}/childAssets, POST /inventory/managedObjects/{id}/childAssets, and DELETE /inventory/managedObjects/{id}/childAssets/{childId}.Child devices denote a relationship type within the Cumulocity inventory’s domain model used to establish parent-child links that reflect the communication hierarchy, connecting a parent device (often an agent or a gateway) to the downstream devices it manages.
GET /inventory/managedObjects/{id}/childDevices, POST /inventory/managedObjects/{id}/childDevices, and DELETE /inventory/managedObjects/{id}/childDevices/{childId}.The Cockpit application is one of the default applications of Cumulocity. It provides a self-service UI to manage and monitor IoT assets and data from a business perspective, like managing assets, visualizing data, working with dashboards and managing reports.
See also Cockpit in the documentation.
/inventory/managedObjects) for assets/groups, Measurement API (/measurement/measurements), Event API (/event/events), Alarm API (/alarm/alarms). Cockpit-specific configurations like dashboards are stored as managed objects.The communication hierarchy models how devices are connected to the platform from a network communication perspective. It is built using the child devices 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.
See also Cumulocity’s domain model in the documentation.
GET /inventory/managedObjects/{id}/childDevices, POST /inventory/managedObjects/{id}/childDevices, and DELETE /inventory/managedObjects/{id}/childDevices/{childId}.The configuration management feature allows administrators and applications to remotely manage the settings of a device. This is typically achieved by creating and applying a configuration operation.
See also Managing configurations in the documentation.
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.The connection monitoring feature allows identifying devices 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.
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.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.
See also Private Preview, Public Preview and General Availability.
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.
/inventory/managedObjects), Application API ()/application/applications), and User API (/user/users).Cumulocity Core is the foundation of the Cumulocity platform. It comprises all major components such as the default applications (Administration, Cockpit and Device Management), the Cumulocity operational store, microservices, security, REST API, MQTT API, and smart rules.
Cumulocity Datahub is a Cumulocity application for periodically offloading data from the Cumulocity operational store to a data lake and querying the data lake contents.
See also DataHub in the documentation.
/service/datahub/) to proxy query-related requests to the Dremio engine.The Cumulocity Developer Codex is Cumulocity’s comprehensive design system aimed at developers building custom web applications. The Cumulocity Developer Codex provides a set of UI guidelines, a library of reusable Angular components (Web SDK), and styling utilities to ensure that custom applications maintain a consistent look and feel, and user experience with standard Cumulocity applications.
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 in the documentation.
The Cumulocity OpenAPI Specification is a complete OpenAPI specification (following the OpenAPI 3.0 standard) for the Cumulocity REST API, available at 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.
The Cumulocity operational store is an internal datastore where all data (such as alarms, events, inventory, and measurements) are stored in base collections.
/alarm/alarms, /event/events, /inventory/managedObjects, /measurement/measurements. Direct API access to the store is not provided.The Cumulocity Sensor App is a free smartphone application for iOS and Android that turns a smartphone into a managed IoT 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 and alarm triggering, and remote device operations, providing an easy entry point for exploring Cumulocity’s IoT capabilities.
See also Cumulocity Sensor App in the documentation.
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 models or write custom EPL Apps to analyze data streams, generate new data, create alarms, or trigger operations on devices.
See also Analytics > Streaming Analytics in the documentation.
/service/cep/diagnostics, /service/cep/monitoring) or Prometheus as described in Troubleshooting and diagnostics.Dashboards are customizable views within applications like the Cockpit application, composed of various widgets, used to visualize data, monitor assets, and potentially trigger actions.
See also Working with dashboards in the documentation.
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 (POST /inventory/managedObjects and PUT /inventory/managedObjects/{id}).The data broker functionality is an optional feature in Enterprise tenants which lets you share data selectively with other tenants.
See also Data broker in the documentation.
The data explorer is a visualization tool for exploring, comparing, and analyzing IoT data, such as measurements, alarms, and events, from specific assets or across all assets.
See also Data explorer in the documentation.
/measurement/measurements and /measurement/measurements/series) to fetch and visualize data.Data lakes are used in the context of Cumulocity DataHub. A data lake serves as a storage container for offloaded data, for example, ADLS Gen2/Azure Storage (Azure), S3 (Amazon), or a NAS.
A data point is a configuration that defines how a specific measurement time series is visualized in UI views like the data explorer and dashboards. 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.
GET /measurement/measurements/series). Visualization properties are stored within a dashboard’s managed object configuration or in the 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, identified by its 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 are displayed consistently.
See also Data point library in the documentation.
c8y_Kpi.A device is a special type of 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.
c8y_IsDevice fragment. The identity is managed via the Identity API (/identity/externalIds), operations via the Device Control API (/devicecontrol/operations), and data sent/received via the Measurement API (/measurement/measurements), Event API, and Alarm API.Device agents are software components that translate a device-specific communication protocol into the standard Cumulocity REST or MQTT-based protocol, enabling secure, bi-directional communication. Device agents can be deployed on the device itself (for example, on a gateway) or run as server-side microservices within the Cumulocity platform.
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).The Device Management application is one of the default applications of Cumulocity. It provides functionalities for connecting, managing and monitoring devices and allows to control and troubleshoot devices remotely.
See also Device Management application in the documentation.
/inventory/managedObjects), Identity (/identity/externalIds), Device Control (/devicecontrol/operations), and data APIs (Measurement/Event/Alarm).A device protocol defines how data from a specific device type is transferred into the Cumulocity platform and translated into the Cumulocity data model.
The device replacement feature allows the replacement of physical devices without losing the historical data associated with the original device.
/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.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. This data-driven digital counterpart enables monitoring, analysis, and optimization of physical assets by combining sensor measurements with business context.
The Digital Twin Manager (DTM) is a schema-based modeling application in Cumulocity that enables users to create and manage data model schemas, which serve as blueprints for modeling assets, properties, and other managed objects, acting as reusable templates within the platform.
See also Digital Twin Manager in the documentation.
/service/dtm/) to manage the lifecycle of asset models, asset properties, and asset instances.Cumulocity stores all operational data, such as managed objects, alarms, and measurements, as documents. Documents are the fundamental JSON structures used in Cumulocity REST APIs.
The domain model is the conceptual framework that defines how Cumulocity structures, represents, and relates different types of information (inventory, measurements, events, operations). Data is organized as modular fragments within JSON documents, allowing flexible extension and customization.
See also Cumulocity’s domain model in the documentation.
Edge Server is an informal term for Cumulocity Edge. See Cumulocity Edge.
An Enterprise tenant is a tenant type in the Cumulocity tenant hierarchy that provides advanced administrative capabilities, primarily focused on managing multiple subtenants. An Enterprise tenant (sometimes also referred as “parent” tenant) can create, manage, and bill its own subtenants and enables features like custom branding, custom domain names, and user hierarchies.
See also Enterprise tenant administration in the documentation.
POST /tenant/tenants). Application and branding subscriptions for subtenants are managed via POST /tenant/tenants/{tenantId}/applications.Apama EPL is a domain-specific, event-driven programming language with a syntax similar to Java, designed for writing programs that process events in realtime. In Cumulocity, EPL logic is typically implemented as EPL apps within the Streaming Analytics application.
EPL Apps is part of the Cumulocity Streaming Analytics application. It allows you to develop a single-file EPL application directly within Cumulocity using Apama EPL, giving you a pro-code environment to define your streaming analytics applications.
A Cumulocity event is a time-stamped informational record that transmits real-time information on any state change of a device or asset. Next to Cumulocity events, the following types of events are used within the Cumulocity platform:
/event/events). Key properties include type, time, text, and source.Export is a feature of the Cockpit application that allows users to extract a limited amount of platform data, such as measurements, alarms, or events, into CSV or XLSX files. Exports can be configured with filters for specific devices, time ranges, and data fields. Recurring exports can be scheduled in the Cockpit application.
See also Exports in the documentation.
/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 are official or community-supported packages that add new functionalities to the Cumulocity platform. They can include plugins, which add features to existing applications 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.
/application/applications) and contains an isPackage flag inside the manifest. Additionally, extensions use the Versioning API, to ensure compatibility when they are integrated into an application.Fragments are JSON objects used to extend Cumulocity’s core data types, such as managed objects, events, and operations. They are the primary mechanism for creating a flexible and extensible domain model, allowing the representation of any asset or device without a rigid, predefined database schema.
c8y_Position fragment via PUT /inventory/managedObjects/{id}).The fragment library defines the data structures that are used in Cumulocity for device management activities like, for example, configuration management. The data structures are expressed as fragments that can be used inside managed objects, operations and other resources.
See also Fragment library in the documentation.
In the Continuous Deployment model, General Availability (GA) refers to the availability of a feature to all customers (as compared to Private Preview and Public Preview). In the 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.
A type of role in Cumulocity’s permission model that contains permissions applying to all data within a tenant. Unlike inventory roles, which grant permissions to specific assets or groups, global roles apply tenant-wide.
For details, see Global roles in the documentation.
/user/roles and can be assigned to users via POST /user/users/{username}/roles.A group is a special type of asset used to organize devices and other assets for structural and permission-management purposes. Groups support flexible organization and, when paired with inventory roles, can grant or restrict user access to the contained devices and assets.
/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).The inventory stores all master data for devices and assets, including their configurations and relationships, and serves as the digital twin of physical or logical entities within Cumulocity.
/inventory/managedObjects). It allows creating (POST), retrieving (GET), updating (PUT), and deleting (DELETE) managed objects.Inventory roles contain permissions that grant access to specific groups of devices or assets in the inventory. They allow fine-grained authorization to particular assets or device groups and their associated data.
For details, see Inventory roles in the documentation.
/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.The isolation level defines how microservice instances are shared among tenants. 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.
The location represents the geographical position of a managed object. The location is represented by the standard c8y\_Position fragment, which contains altitude, longitude, and latitude coordinates. Managed objects with this fragment can be displayed on Map widgets.
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}).Maintenance releases are provided for supported Yearly releases and contain important bug fixes but no new features, ensuring stability and security for long-term supported versions of the platform.
Managed objects are the core building blocks of the Cumulocity inventory. A managed object is the primary digital record (digital twin) used to represent entities such as devices, assets, logical groupings, or application components. Managed objects are used to model data sources (for example, an IoT sensor), and all related data, such as events, alarms, and operations, linked to the managed object. When referred to as a “source managed object”, it denotes the managed object representing the origin of that data.
/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": {}}.The Management tenant builds the highest level in the Cumulocity 3-level 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, and holds exclusive platform-level administrative capabilities.
/tenant/tenants) but with elevated, platform-wide permissions.A measurement is a time-stamped reading or statistic collected from a sensor or device and linked to a source managed object. Measurements are organized into one or more fragments (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.
/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.Microfrontend refers to an architectural style for web applications where the UI is decomposed into smaller, independently deployable applications or plugins. Cumulocity’s web UI is built on this architecture with the Web SDK, allowing a “shell” application (like Cockpit) to be extended by loading “remote” modules (plugins) from other web applications.
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.Microservices are server-side applications 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.
See also Microservices in the documentation.
A microservice manifest is a required JSON file (cumulocity.json) included within a microservice package. It provides the necessary metadata for the platform to manage the microservice’s deployment, lifecycle, and integration.
See also Microservice manifest in the documentation.
POST /application/applications/{id}/binaries.The Cumulocity Microservice SDK is a set of tools, libraries, and documentation that helps developers build custom microservices 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-aware applications. 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.
In Analytics Builder, a model is a visual representation of analytic logic created by connecting pre-built blocks via wires 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.
Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers (tenants). 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).
See also Multi-tenancy in the documentation.
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 currently in use.
hookNavigator provider to add new menu items (nodes).An offloading pipeline is a configurable job within Cumulocity DataHub that defines the process of extracting data from a specific collection in the operational store, transforming it, and loading it into a target table within a data lake.
Operations are instructions sent to a device or asset to perform a specific action, such as control, configuration, or maintenance. Operations are linked to a source 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.
The user who creates an inventory object (such as a device or a group) automatically becomes its owner. Ownership grants users full permission (ADMIN, READ, CHANGE) for that specific object to ensure that they can fully manage the resources they create.
POST /inventory/managedObjects, the owner field of the new object is automatically set to that user’s ID.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, inventory). Permissions are not assigned to users directly. Instead, they are grouped into roles.
See also Managing permissions and roles in the documentation.
Permissions are granted via roles, which are managed through the 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 denotes a feature release stage in the Continuous Deployment model where a new feature is made available to a limited, invitation-only group of selected customers for feedback and testing. See also, Public Preview and General Availability.
The processing mode is a mechanism that allows clients to control how Cumulocity handles incoming data (measurements and events) 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).
X-Cumulocity-Processing-Mode HTTP header. For MQTT, specific topics are used (s/, t/, q/, c/) to specify the processing mode.Public Preview denotes a feature release stage in the Continuous Deployment model 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. See also, Private Preview and General Availability.
RBAC (Role-Based Access Control) is a security model used by Cumulocity in which permissions are grouped into roles, and these roles are then assigned to users or user groups. This allows administrators to manage access based on a user’s function or responsibilities.
/user/roles and /user/inventoryroles are used to define roles, while endpoints like /user/users/{username}/roles assign them to users.Release notes are published for each Cumulocity Yearly release and its subsequent maintenance releases, detailing new features, bug fixes, and API changes. Release notes help users track changes and understand their impact on deployments.
Reports are global dashboards, accessible in the Cockpit application, and visible across the entire tenant regardless of the asset hierarchy. A report serves as a customizable container for widgets to visualize and track tenant-wide data like applications, alarms, and assets.
See also Working with reports in the documentation.
/inventory/managedObjects). They are basically a special type of dashboard.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.
Roles are named collections of permissions that can be assigned to users and/or devices to determine the level of authorization on the platform. Roles are the central component of Cumulocity’s RBAC model. The platform distinguishes between global roles (tenant-wide) and inventory roles (specific to the device data in the inventory).
See also Managing permissions and roles in the documentation.
/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.A service user is a non-human user account that is created automatically when a tenant subscribes to a microservice. It allows the microservice to interact with the tenant’s data via the REST API for background tasks, independent of any end-user’s session.
/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 environment variables.Smart groups are groups whose membership is dynamically determined based on device properties matching defined criteria, rather than static assignment. This is a feature of the Device Management application.
See also Using smart groups in the documentation.
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.SmartREST is a lightweight, CSV-based device protocol to exchange data between devices 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.
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 when a measurement exceeds a specific threshold.
The platform provides two versions of this feature:
See also Smart rules collection or Smart rules (NEW) plugin in the documentation.
A standard tenant is a tenant that does not have tenant management capabilities. Unlike an Enterprise tenant or Management tenant, a Standard tenant lacks multi-tenancy features and cannot create subtenants.
See also Standard tenant administration in the documentation.
In Cumulocity, a subscription denotes the process by which a tenant is granted access to an web application from the Administration application. A superior tenant (like an Enterprise tenant or the Management tenant)) subscribes applications and microservices to its subtenants.
See also Subscribing applications in the documentation.
POST /tenant/tenants/{tenantId}/applications) and the Application API (POST /application/applications/{applicationId}/subscription). Microservices use GET /application/currentApplication/subscriptions to list subscribed tenants.A subtenant is a tenant created and managed under a parent tenant (either an Enterprise tenant or the Management tenant) within the Cumulocity tenant hierarchy.
/tenant/tenants) by an administrator of a parent Enterprise tenant or Management tenant.A tenant represents a logically isolated data space within Cumulocity, typically corresponding to a customer or organizational unit. It has its own users, devices, applications, and data (see Cumulocity’s domain model).
/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 (/tenant/options).The tenant domain refers to the domain name used to access a Cumulocity tenant, in the format <tenant-name\>.\<instance-name\>. It is used for login and API access and is distinct from the tenant’s unique identifier (tenant ID). For example, a tenant named “acme” on the instance cumulocity.com would have the tenant domain “acme.cumulocity.com”. Enterprise tenants and their subtenants can optionally configure custom domains for access using the platform’s custom domain feature.
The tenant hierachy refers to the structure organizing tenants in Cumulocity, involving a Management tenant at the top, Enterprise tenants below it, and Standard tenants at the lowest level.
See also Tenant hierarchy in the documentation.
/tenant/tenants). Creating a subtenant (POST /tenant/tenants) under a parent tenant establishes the hierarchical link.A tenant ID is a unique identifier assigned to each tenant. The tenant ID is often used as a prefix in the username for authentication (for example, \<tenantID\>/\<username\>).
Tenant options are configurable key-value pairs associated with a tenant, used to customize platform behavior, application settings, or store tenant-specific configurations.
/tenant/options). Options can be created (POST), retrieved (GET), updated (PUT), and deleted (DELETE).
There is a mechanism to encrypt 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 policies are predefined sets of tenant options and retention rules that can be created in a Management tenant or Enterprise tenant and applied when creating new subtenants to ensure consistent initial configurations. Tenant policies are created and managed in the Administration application.
See also Tenant policies in the documentation.
/inventory/managedObjects). When creating or updating a policy the request body must follow a specific format, for example, must contain the c8y_TenantPolicy fragment.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/.
Thick Edge is an informal term for Cumulocity Edge, see Cumulocity Edge.
thin-edge.io is an open-source software framework recommended by Cumulocity for custom device integration. It provides components and tools to connect devices to the platform, particularly suitable for implementing device-side logic.
An individual account within a Cumulocity tenant, identified by a unique username. Users are assigned roles with specific permissions that determine their access rights to data and functionalities.
/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.An optional feature allowing the creation of hierarchical relationships between users. This enables parent users to manage their sub-users and delegate permissions.
/user/users). Creating/updating a user with an owner property establishes the hierarchy.A Cumulocity web application is a browser-based application hosted on the Cumulocity platform. This includes the official Cumulocity applications (such as Cockpit, Device Management, Administration, and Streaming Analytics), as well as custom applications built by customers, optionally using the Cumulocity Web SDK.
/application/applications) with type: HOSTED. They are uploaded as ZIP archives containing at least an index.html file and optionally a cumulocity.json file.The Cumulocity Web SDK is a development framework that enables users to build extensions or web applications for deployment on the Cumulocity platform. It provides secure API access, access to default UI components, and support for custom branding, allowing developers to create tailored applications that seamlessly integrate with the platform’s ecosystem and maintain a consistent user experience.
See also Web SDK in the documentation and the Cumulocity Developer Codex.
@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.A widget is a configurable UI component that can be added to a Cumulocity dashboard to visualize IoT data. Widgets can display maps, images, graphs, tables, and other information such as alarms, measurements, and events.
In Analytics Builder, wires are used to connect two or more blocks with each other for data transfer between the output port of one block and the input port of another block.
Yearly releases are provided in a yearly cycle and named after the year, for example, Cumulocity 2025 release. The General Availability (GA) for a Yearly release is scheduled for the 31st of March of the respective year. See also, Continous Deployment model.