Getting Started
Basic Concepts
Advanced Concepts
How-to Guides
Building integration flows
Data transformation
Integration patterns
Developing Components
Tenant Management
CRM components
ERP components
E-Commerce components
Marketing-related components
Finance-related components
Office components
Protocol components
Service components
Database components
Utility components
Component Descriptor
Version 3.19.0 is full of new stuff!


We are in a constant state of UI honing, to make it even more convenient for you. First of all, we fixed the navigational menu, so it does not hide if you move the cursor away from it. To close the menu, click “hamburger” icon again.

IMPORTANT: Please don’t forget that from now on your company logo will be moved to the navigation panel. For proper display, please make sure that your logo complies with the following requirements:

  • Logo shape - square

  • Logo size = 40x40 pixels (smaller logos will be centered with whitespace around them)

  • Logo format - .PNG or .SVG


You can now use Recipes to simplify Flow creation. Basically, a Recipe is a template of a working integration Flow. It has the following conditions:

  • A Recipe may not reference any credentials

  • A Component in a Recipe must always be versioned

  • Mapping expressions may contain variables to be replaced with values during Recipe activation. You can perform CRUD operations with Recipes and create a flow from a recipe using API. You can find examples here. Please note that the section is an experimental API.

IMPORTANT: Recipes are beta right now, so we don’t recommend using them with critical data or production.


Not to let you waste any time, we have added handy alerts that will notify you of any important changes in your flows statuses:

  • All Contract owners will receive emails upon exceeding 80%, 85%, 90% and 95% of resource usage quota

  • All users that subscribed to errors on a particular integration Flow will receive an email if the Flow gets suspended


You can now send a sample request to Webhook. Here is the new process of Webhook setup:

1. Generate a unique URL for the Webhook to post sample data to and present it in the UI

2. Send a sample request to the given URL. Once the request has been sent, it is stored in the DB.

3. The sample is retrieved by ID and is used for mapping. Sample URL is active for 10 minutes.

List Of Fixed Bugs

We were totally dedicated to improvements this month, so all the discovered bugs were immediately fixed before going into production.

Frontend stuff

Introduced FRONTEND_NO_EXTERNAL_RESOURCES config variable. If set to "true", then frontend will use scripts, styles and fonts from the same domain, without external CDN usage. If you want to use external CDNs, do not specify this variable.

To customize the link that leads to Component creation instructions, when creating a new Repository, PATCH your Tenant with:


If docs_base_url is not specified the repository page docs link will set to default value.

Dockerized Slugs

This is very cool, but quite new and experimental, so use at your own risk!

You can now build components as docker images via Gitreceiver. Gitreceiver pushes images into docker-registry, then docker at k8s nodes pulls images from that docker registry to run them.

We introduced ksonnet component (docker) and 4 new parameters:

1. docker_registry_replicas Just number of replicas of docker registry deployment. Clearly it should be greater then 1. You can change this value any time you want.

2. docker_registry_secret_name. Admiral will use this secret while creating pods as authorization secret in docker registry. This secret should be defined in tasks namespace, it should contain login/pass and server (see docker_registry_uri) for authorization in docker registry (docker-registry type). Probably elasticiotasks value is good enough. Generally you can change this value, but:

*a) be sure than proper secret exists in tasks namespace.

b) be sure that you’ve restarted admiral after change.

c) It’s better to remove previous secret only when all pods, that was defined with it will die. Otherwise that won’t restart in case of failure.*

3. docker_registry_uri. Value is used by gitreceiver to find out where to push newly built images and by admiral to create fully-qualified image name of docker image for pod. Typically value looks like this: “http://$LOGIN:$PASSWORD@”. $LOGIN and $PASSWORD should be same as secret mentioned above. Secret also should reference to IP address and port. Port is arbitrary from NodePort range (30000-32000 in default K8S installation). We don’t recommend changing it during installation runtime. URl’s path – anything you like. elasticio seems quite reasonable and I don’t see any reasons to change it. Also, it is better not to edit this value during lifetime of installation. Host MUST be for all installations.

4. docker_registry_http_secret. Just a good random string of any length. Used by docker registry for its own crypto magic. Changes requires restart of all docker-registry pods.

Ksonnet scripts install everything and maintain all constraints between ksonnet entities. To push component as docker it’s required to add "buildType":"docker" into component.json file in component repository.

Other Stuff

We replaced custom_links field for Tenant with custom_nav_menu_items. PATCH your Tenant to display the “Quick Help” menu:

   "title":"Quick Help",
       "title":"Help Center",

URLs in custom_nav_menu_items now supports url parameters (workspaceId, contractId, tenantId, etc.). When a URL has placeholders http://custom-url?workspaceId={workspaceId}&contractId={contractId}, those placeholders are substituted with real parameters. custom_nav_menu_items supports a 2-level structure.

IMPORTANT: The following Tenant configs are deprecated now:

connectorCatalogUri flowCatalogCurrentProjectSpaceUri infoSupportUri infoVideoUri infoDocumentationUri