This is documentation for the old, first-generation Kaa platform v0.x.
Next generation Kaa Enterprise IoT platform is now available! Try it free with a 30-days trial.
Kaa Enterprise documentation is here.
. . .




A virtual entity that operates within the actor gateway to impersonate a physical device, virtual object, library, etc. as a Kaa endpoint.

Actor gateway

A Kaa-based component that initializes, manages, and uses actors to represent endpoints connected to the gateway. Deployments with an actor gateway are intended for IoT environments that use proximity or non-Internet communication protocols, and thus have to be bridged to communicate to the Kaa server.

Administration UI

A web service that implements a user interface for managing Kaa users, applications, schemas, etc.

Application profile

A certain version of a Kaa application whose behavior is defined by a specific set of extensions and their configurations. One Kaa application can have multiple profiles that are stored as different versions of that application. Application profile is stored and managed on the Kaa server.

Application token

An auto-generated unique identifier for a Kaa application. You can copy Application token from the main window of the Administration UI.
See Your first Kaa application documentation section.

Avro UI form

A component of the graphical user interface in the Administration UI. Avro UI forms are used to create Kaa data schemas and data records in the visual environment as opposed to JSON syntax.


Bootstrap service

One of the three main service types used in Kaa. The other two are Control service and Operations service. A Bootstrap service is responsible for directing endpoints to Operations services. Kaa endpoints have an embedded list of Bootstrap services set up for certain Kaa instance. Kaa clients use a Bootstrap services list for a certain Kaa instance embedded in the SDK. Bootstrap services maintain their lists of available Operations services by coordinating with the ZooKeeper.
See Architecture overview documentation section.


Common type (CT)

A versioned definition of data schema structure, managed within the Common type library. Any CT can be reused in multiple places of Kaa instance.
See Common type library documentation section.

Common type library (CTL)

A repository of common types that can be reused in Kaa modules.
See Common type library documentation section.

Control service

One of the three main service types in Kaa. The other two are Bootstrap service and Operations service. Control service manages the system data, processes API calls from the Administration UI and external integrated systems, delivers notifications to Operations services.
See Architecture overview documentation section.


Endpoint (EP)

An independently managed client-side entity within a Kaa deployment. Kaa represents every managed entity – device, sensor, mobile phone, etc. – as an endpoint.
See Architecture overview documentation section.

Endpoint group

An independently managed group of endpoints within a Kaa application. An endpoint group is defined by a set of filters against the endpoint profile. Those endpoints, whose profiles match the filter, are automatically assigned to a group. Any endpoint can be a member of multiple groups at the same time.
See Endpoint groups documentation section.

Endpoint profile (client-side, server-side)

A structured set of data that describes specific characteristics of an endpoint. Endpoint profiles are used to classify endpoints into endpoint groups. The values for the client-side endpoint profiles are specified by Kaa client.
The server-side profile contains the data about endpoint properties that are controlled by your server-side applications. For example, client subscription plan, device activation flag, etc.
See Endpoint profiles documentation section.

Endpoint SDK

A library used for communication, data marshaling, persistence, and other functions performed between an endpoint and Kaa server. An SDK is used to create Kaa clients on the connected endpoints of the same Kaa application within a Kaa cluster.
See Kaa SDK type and Using Kaa endpoint SDKs documentation sections.


Group all

A default, non-editable group created for each Kaa application. The weight value of this group equals to 0. The profile filter of this group is automatically set to true for every profile schema version in the system. The group all includes every endpoint registered in the application. See Using endpoint groups documentation section.


Kaa administrator

The highest-level administrator of Kaa instance. Kaa administrator has the rights to create, edit and delete tenant administrators.
See also tenant developer.

Kaa application

An integrity of configurations and code that utilizes Kaa platform functionality for a specific use case.
See Your first Kaa application documentation section.

Kaa client

A client-side entity that implements the endpoint functionality. Kaa client typically uses Kaa endpoint SDK to communicate to Kaa server.

Kaa cluster

A Kaa cluster represents a number of interconnected Kaa server nodes. Every Kaa cluster runs a particular Kaa instance.

Kaa extension

An independent software module that implements an isolated set of functions aimed at extending the communication capabilities between Kaa server and Kaa clients.

Kaa instance (Kaa deployment)

A set of specific Kaa platform functionality that is logically integrated and managed as a single system.

Kaa platform

A multi-purpose middleware platform for building complete end-to-end IoT solutions, connected applications, and smart products. The Kaa platform comprises Kaa server and endpoint SDKs.
See Key platform features documentation section.

Kaa Sandbox

A preconfigured virtual environment designed for the users who want to use their private instance of Kaa platform for educational, development, and proof-of-concept purposes. The Sandbox also includes a selection of demo applications that illustrate various aspects of the platform functionality.
See Getting started documentation section.

Kaa SDK type

SDK type in Kaa is determined by the programming language used to build an SDK. Currently, there are four SDK types supported in Kaa: C, C++, Objective-C, Java.
See Using Kaa endpoint SDKs documentation section.

Kaa server

A Kaa platform component that functions as its back-end part. The server exposes integration interfaces and allows performing administrative tasks.
See Architecture overview documentation section.


Load balancing strategy

A particular way of rebalancing the workload between the Operations services within a Kaa cluster to achieve the desired load for each service. See Active load balancing documentation section.

Log appender

A service utility within the Operations service. Operations service receives logs from the endpoints and sends them to the log appender. Log appender writes the logs to a specific single storage as defined by the log appender type and configuration. Kaa provides several default implementations of log appenders. You can create custom log appenders.


Operations service

One of the three main service types in Kaa. The other two are the Bootstrap service and Control service. The operation service is mainly intended for data exchange and synchronization with endpoints.
See Architecture overview documentation section.

Owner verifier

A server component that handles verification of endpoint owners.
See Owner verifiers documentation section.


Profile filter

A predicate expression based on the Spring Expression Language and designed to filter endpoint profiles. By applying profile filters, Kaa platform identifies which endpoints should be attributed to a specific endpoint group.
See profile filters documentation section.



A business entity that uses a part of or a whole Kaa instance to independently run Kaa applications.
See Tenants and applications management documentation section.

Tenant administrator

A Kaa user who has the rights to manage applications, users and event class families within a tenant.
See also Kaa administrator and tenant developer.

Tenant developer

A system user that creates and manages application profiles based on the customer requirements. Tenant developers set up schemas, create endpoint groups, and control notification processes.
See also Kaa administrator and tenant administrator.


A component that implements communication between Kaa clients and Kaa server.