Requirements for Public integrations

If you are developing an integration that would be useful to an Kommo user, we would be happy to publish the integration in our marketplace.

Technical account

To interact with developers who wish to publish an integration in our marketplace, we have created a convenient and quick way to interact with the integration department – a technical account. In order for us to make your account technical, you need a new account, which you can register on yourself. After that, you need to activate chat with technical support, and write the following “Need to chat with the integration department to create a technical account”.

Such an account is designed to develop and test the widget (NOT to run your business). The Kommo technical user ( is added to this account, so that if integration errors occur, the integration department developer can log into this account and replicate the error on his own. For those who have not yet published the integration, an account is issued for 1 month. After publication, the account will be renewed on a regular basis automatically.


For authorization, Kommo uses the oAuth 2.0 authorization method, which is more secure and devoid of many disadvantages when compared to the API key method.

General requirements

In order for the integration to be understandable for the client, you must follow the recommendations described below.

Easy to use

Non technical users must be able to understand:

  • how to enable the integration
  • how to configure it
  • how to work with it
  • where they can get support

The more convenient the integration, the more people will use it.

Development quality

Most errors known to integration developers can be tested in advance in a technical account, so a version with all the fixes would be submitted for publication
In the event of a failure or emergency, a message should be displayed with the reason and contain contact information as a notification to a user.

Integration should not collect information that is not required for the integration to function.
The integration should contain a link to a privacy policy, as an example you can use the Kommo privacy policy.

If the integration functionality depends on the Kommo tariff (subscription) plan chosen by the user, the information must be placed in the widget description.
Please note: the mentioning of payment for Kommo licenses via Kommo Partners in the description is not allowed, regardless of the way of mentioning.

Non-Competition Agreement
An integration developer is not allowed to develop systems similar to Kommo.

Advanced settings
When adding an additional page of advanced widget settings in the “Settings” section, the page name should not repeat the names of standard pages, nor should it mislead the user.

Not allowed:
Invoice payment

The page should be located after all our standard pages in the “Settings” section.

Publish en and es integrations

Integration deployment can be either monolingual or multilingual.
In the event that you are interested in placing in the Kommo US / ES marketplace, there are a number of requirements for successfully passing moderation.
Integration images (logo, tour) for English and Spanish languages containing text must be in the corresponding language.
All other images, videos, and instructions should also be in English or Spanish.
The support phone number must begin with +1, it is allowed to use other country codes, but only with English-speaking support.
All links should lead to sites in English or Spanish, with content in corresponding language. We will check:

  • Images
  • Contact Information
  • Addresses
  • Offer and licenses
  • Prices
  • Other site content

All prices must be in dollars or euros, while the payment system used must work in America and the European Union, for example – PayPal
The integration description should not mention the .ru domain, including support mail. archive requirements
Once you are ready to upload the widget, do not forget to delete unused files, pictures, scripts and other files that are not used in the integration. They should not be in the archive.
The content of minimized and / or obfuscated files complicates moderation; avoid such things when creating a widget archive. All text files (.js, .css, .json, .md, etc …) must be in UTF-8 encoding without BOM, and also use Unix line feed (\ n).

List of required files that must contain:


  • logo.png
  • logo_main.png
  • logo_medium.png
  • logo_min.png
  • logo_small.png

Manifest.json file
The following fields are required:

  • name
  • description
  • short_description
  • locale
  • installation
  • locations
  • settings

No need to specify the scope in the manifest (in the “locations” parameter) that you do not use in the integration.

I18n Files
Localization files must contain text in the appropriate language. That is, the i18n / en.json file should not contain Russian texts, and should not mention .ru domains.
All links in en.json and es.json files should lead to sites in English or Spanish, respectively.

Integration Widget Requirement
The client part of the integration (widget) should not overlap Kommo controls, and should not prevent the user from interacting with the Kommo interface.

Interface changes
Integration should not change interfaces that are not included in the allowed list.
It is forbidden to change the left menu, except for cases described in the documentation.
The widget block cannot be placed below the notification center block on the left side of the menu.

When using Drag & Drop feature, the drop area should not be located in:
left menu. The rectangle located at the top of the user interface with the width of the scope and 65px height areas with system controls (buttons for settings, save, import, etc …)
It is forbidden to hide / modify / replace ratings and reviews in the integration section and the widget settings modal window.
When saving the integration settings, the “Save” button should be located at the bottom of the modal window.
Virtual clicks on the “Install” button are prohibited.
Manipulations with global CSS selectors are forbidden.

Not allowed:
input { background: red; }

A widget should not have common classes with our system in the css files. All styles should be specified relative to the root widget selector. This makes it possible to redefine any styles inside the widget without affecting the system styles.

.control-select { color: green }

Not allowed:
.control-select { color: red }

Only explanatory comments in the widget are allowed.
// our signature color
Not allowed
// background: #fafafa;

Connect files with styles
Style files should be included strictly in accordance with the documentation.
The more readable and understandable code you send for moderation, the faster the moderation process will go through, as it is done manually by specialists from the integration department.
Only explanatory comments in the widget are allowed.
// get account id.
Not allowed
// var a = APP.constant(‘account’).id
Development traces
The integration code should not contain:
test data
alert and confirm
and other development traces that are not needed for integration work
It is possible to use console.debug for logging information important for the widget to work, so that later the developers could replicate issues in an emergency situation.
If an emergency occurs, it is possible to use console.trace, but only inside the following blocks:
Inside catch block
In the onRejected Promise Argument
All other methods of the console object, as well as other uses of console.trace, can clog the console
Nonexistent variables
All variables in the widget must be declared before use, the syntax must be correct.
Using the global variable APP
The list of allowed calls is described in the article “Environment Variables”.
We do not guarantee the operation of undocumented environment variables in the future, therefore we strongly recommend that you refrain from using them.
The widget should not affect the data in the global variable APP, it can only read data from it.
Synchronous requests are forbidden (async: false), since their use slows down the loading of other scripts, which ultimately affects the speed of loading pages of the service.
External dependencies
The widget should not include external dependency files through document.createElement (‘script’) and insert this element directly into the head.
All external dependencies must be connected via requirejs in the dependency block in define.
Additional plugins or other external connections to the widget should not be loaded from external resources with the exception of public libraries.
A list of external resources that it is advisable to use when connecting libraries, as you cannot load your own libraries there:
jQuery CDN

  • The list of external resources that can be used when connecting libraries, but we will check each used library:


    Connect styles from cdn
    Due to the restriction on the use of global selectors, it is forbidden to connect styles from an external cdn if the requested file contains at least one global selector.
    Additional files uploading from CDN
    If you need to use some kind of library, for example, jquery.datepicker, this library can be connected via CDN.
    At the same time it is important for us, for security purposes, that it is a trusted CDN, which you do not influence in any way.
    Continuing the example with jquery.datepicker, you can easily find a CDN for it, where a link to the project repository will be indicated.
    Thus, we will understand that this is not your datepicker implementation, but a third-party library.
    The only limitation to such libraries we connect: they must have at least a thousand downloads per month.
    You can use iFrame in your code, however there is the following restriction: you cannot execute code obtained from the iFrame
    The widget code should not be based on the switcher styles (switcher__on, switcher__off) – they must be removed from the system.