Rebranding Requirements

We are currently rebranding, and amoCRM global will be known as Kommo with the domain kommo.com

Of course, first of all we are a CRM system, but for many international clients we are more than a CRM system, so we decided to develop our brand. You can read more about our rebranding.

In this article, we will talk about the changes that will occur with the API, integrations, widgets and marketplace, in connection with the rebranding. Let’s share recommendations and pay attention to possible problems.

This article will be quite useful to you if you are an integration developer and can answer at least one question positively:

  • Is your integration available in any of these languages [English-Spanish-Portuguese]?
  • Does your integration already work with accounts in amocrm.com?
  • Is your integration available on kommo.com marketplace?
  • Does your integration have an archive and is it made from script.js requests to third-party servers directly?

This article will help you adapt your integrations and widgets to work on different domains.

A brief summary of the changes:

  • Accounts amocrm.com now available on kommo.com
  • The API is currently available on amocrm.com, but in the future we will abandon it, we need to use kommo.com
  • All tokens issued on amocrm.com continue to work on kommo.com
  • The chat API is also currently available on amocrm.com, but in the future we will also abandon it
  • Check that your servers accept requests from kommo.com and don’t delimit them with CORS
  • In widgets, use the APP constant instead of AMOCRM

Redirect amocrm.com accounts to the new domain

The first and most noticeable change is the account domain change. Now amocrm.com accounts are available at the new address SUBDOMAIN.kommo.com.

Currently, when going to the address SUBDOMAIN.amocrm.com, a redirect to the SUBDOMAIN.kommo.com happens for almost all accounts. The exception is active accounts that have integrations that are not adapted to kommo.com. Such accounts are temporarily available on both kommo.com and amocrm.com. In the near future, as soon as the integrations are adapted, we plan to enable redirects for such accounts as well.

It is also important to note that for now the redirect works only for the web version. API methods whose addresses begin with the following masks are not subject to redirection:

  • private/api/*
  • api/v2/*
  • api/v3/*
  • api/v4/*
  • auth2/*

Important notes

  1. In the future, a redirect will also be enabled for API methods. For GET/POST/PATCH/DELETE/PUT requests to API methods, the redirect will come with the HTTP code 308 (Permanent Redirect). The 308 HTTP code allows you not to lose the request method when redirecting, so it is used.
  2. All tokens issued on amocrm.com will continue to work on kommo.com, re-installation of the integration is not required.

Recommendations

We ask you not to use the account ID and the account subdomain as the primary key in your repositories. You can use an auto-increment id field as the primary key. And the account ID and subdomain will simply be the properties of a string in your repository.

Changes to the Chat API

The changes will also affect the chat API. For chat integration in kommo.com, requests must  be made to the host amojo.kommo.com.

Currently, requests sent to the host amojo.amocrm.com are still being accepted. But in the near future, requests will be redirected to amojo.kommo.com with http code 308. If your application does not support redirects, we recommend supporting the new domain and redirects.

Links to media files already come to the domain kommo.com .

At the same time, there will be no changes during the registration of chat channels.

Changes in the Web SDK

If your integration contains an archive and makes requests to third-party resources from the amoCRM/Kommo interface, you need to read the points below and adapt the integration according to the instructions.

CORS

If your integration has an archive with a widget that works in the amoCRM interface, most likely you are making requests to your server.

If these requests are not through a proxy, but directly to your server, you need to check and make sure that your server returns headers clarifying that it accepts requests from *.kommo.com.

Cross-Origin Resource Sharing (CORS) is how servers define restrictions on the execution of browser requests from certain resources.

The AMOCRM constant

Due to the rebranding process, the use of a constant containing the brand name is inappropriate and may mislead users. We have changed the name of this constant to APP, but for backward compatibility, the AMOCRM constant remains available for now.

We now recommend using the APP constant in the js part of the widget for all new and updated integrations.