Skip to content


Kaleido App to App Messaging

The Kaleido messaging service offers a Kafka-backed bilateral app-to-app pipeline for the encryption, submission and decryption of messages between members of an environment. Apps can securely subscribe to pertinent topics for consumption and delivery of data, without reliance on ancillary messaging constructs and subsequent integration of offline data.

The service leverages the On-Chain Registry to establish and verify membership identities. Messages are automatically encrypted and signed, thereby ensuring that only the intended recipient can access the content while also providing proof of the sender’s identity.

Deploying an App to App Messaging Service Instance

You can elect for one of two approaches to provision App to App Messaging Service Instances: Kaleido Console UI or Admin API. For users unfamiliar with the Kaleido REST API, the console interface is the recommended happy path. Both approaches will ultimately result in a new instance of the App to App Messaging Service instance running within the specified environment.

Via the console

  • Navigate to an existing environment and click the + ADD dropdown in the top portion right of the screen and click Add Services.
  • Select the App to App Messaging Service and click ADD.
  • Supply an arbitrary name for the service and click ADD. click DONE to finish the deployment.
  • The newly created App to App Service instance will appear at the bottom of your environment panel under MEMBER SERVICES.
  • The service is ready for use when a green dot appears next to it.

Via the API

NOTE: The following deployment approach assumes a strong understanding of the Kaleido APIs. Please refer to the Kaleido Resource Model for object relationships, the API 101 topic for sample CRUD operations and for detailed descriptions of the various endpoints and routes.

App to app service instances are provisioned against the /services API endpoint and exist as “member” type services.  In other words, the resource is fully-owned and controlled by the provisioning member.

To programmatically create an App to app service instance, specify the consortia and environment IDs in the path and POST to the /services endpoint with a name, the service type and membership ID in the body of the call. The forthcoming sample commands assume that the following environment variables have been set as follows:

export APIURL=""
export HDR_AUTH="Authorization: Bearer $APIKEY"
export HDR_CT="Content-Type: application/json"

If you are targeting an environment outside of the US, make sure to modify your URL accordingly. The ap qualifier resolves to Sydney, while ko resolves to Seoul:

export APIURL=""
export APIURL=""
export APIURL=""

Use the POST method to provision the service and optionally format the output using jq:

# replace the membership_id placeholder with one of your membership IDs
curl -X POST -H "$HDR_AUTH" -H "$HDR_CT" "$APIURL/consortia/{consortia_id}/environments/{environment_id}/services" -d '{"name":"exampleApp2appService", "service":"app2app", "membership_id":"{membership_id}"}' | jq

This will return you a JSON payload containing the service ID.  Next, you can call a GET on the /services endpoint and specify the service ID for your App to App Service instance.  For example:

curl -X GET -H "$HDR_AUTH" -H "$HDR_CT" "$APIURL/consortia/{consortia_id}/environments{environment_id}/services/{service_id}" | jq

This call returns a JSON payload containing the service instance specific details.  Namely it provides the targetable WebSocket URL for sending and receiving messages via Socket IO API.

As is the case with a regular node, the ingress to the App to App service instance is TLS protected. All calls require the presence of application credentials that have been generated against the same membership ID that provisioned the node.