Attribute Dictionary Extension service (ADX) extends the communication capability of Kaa Protocol (1/KP) by allowing connected endpoints to query a shared dataset. This is somewhat similar to the functionality provided by the Configuration Managemen Extension, however, CMX delivers the entire configuration record to the endpoint where ADX allows for granular querying only for the attributes (keys) the endpoint is interested in. ADX serves responses to endpoints using whatever data is provisioned in its corresponding application / appversion configuration as provided by the Kaa Tekton. Configuration data provisioned at the appversion level takes precedence over the application configuration data.


ADX supports a number of interfaces to perform its functional role. The key supported interfaces are summarized in the following diagram.

ADX interfaces diagram

For inter-service communication, Kaa services mainly use REST APIs and messaging protocols that run over NATS messaging system.

Extension service protocol

ADX uses 4/ESP over NATS to exchange messages with endpoints via communication service.

ADX accepts requests from communication servers on /json resource path with the payload specifying the attribute path they are interested in. The path supports the GJSON path syntax for flexibility, and it must be submitted as follows (where 0000E48591757A8E is an example attribute path):

    "q": "0000E48591757A8E"

Let’s take a look at some examples.

Assume that the following configuration is provisioned for ADX under an application:

    "attributeA": "valueA",
    "attributeB": "valueB",
    "nested": {
        "attributeX": "valueX",
        "attributeY": "valueY"

Let us also assume that the configuration under an appversion that belongs to the above application is as follows:

    "attributeA": "valueA2",
    "attributeC": "valueC",
    "nested": {
        "attributeX": "valueX2",
        "attributeZ": "valueZ"

See the following table for sample responses that ADX would serve back to an endpoint that belongs to the above appversion:

Value of "q" in request Response payload Comment
"attributeC" "valueC" Sourced from the appversion config
"attributeB" "valueB" Not found in the appversion config, sourced from application config
"nested.attributeZ" "valueZ" Nested value from the appversion config
"attributeA" "valueA2" Sourced from the appversion config, which has precedence
"nested.attributeX" "valueX2" Nested value sourced from appversion config, though present in application config as well
"nested.attributeY" "valueY" Not found in the appversion config, sourced from the application config

Response payload may be any JSON value as found in ADX configuration by the attribute path.

Tekton integration

ADX is integrated with the Kaa Tekton for centralized application configuration management. It receives configuration update messages from Tekton over 17/SCMP and uses Tekton REST API to retrieve current configs.

See configuration for more information.

Kaa Tenant Manager integration

ADX supports multi-tenancy with each tenant using a separate OAuth 2.0 issuer for authentication, authorization, and resource management. The list of the existing tenants is managed by the Kaa Tenant Manager, which provides REST API for retrieving tenant security configs.

See the security configuration for more details on how to enable multi-tenancy in ADX.

Management interface

ADX exposes an HTTP-based management interface with the following endpoints:

  • GET /health returns 200 OK if the service is up and running properly, and 500 Internal Server Error otherwise. In case of errors, the response payload contains their human-redable descriptions. This endpoint can be used by Kubernetes for liveness and readiness probing.
  • GET /metrics provides service metrics in Prometheus text-based format.