amoCRM Integration

[Vanlon]

I am trying to integrate amoCRM but they have made some changes since the guide was posted on the 3CX blog. There is no longer a place in amoCRM called API. I believe now you go to Integration's and go to +CREATE INTEGRATION. Straight forward here I think on creation.

Once created you get a Secret Key, Integration ID and Auth Code under the Keys and scopes tab.

Under Authorization Tab for the App I just created it says: This app is installed, but no one has given it access yet.

I used the Secret Key in 3CX, but when I hit the test it gives me this:

Server returned a non successful status code - HTTPStatusCode=Unauthorized - Reason=Unauthorized - Content={"response":{"error_code":"110","error":"Invalid user name or password","ip":"xxx.0.201.xxx","domain":"xxxxxxxx.amocrm.com","server_time":1627006750}} Started scenario with empty id Started Initialization Request text: https://westlock.amocrm.com/private/api/v2/json/accounts/[email protected]&USER_HASH=xxxxxxxxxxxxx3-4af2-a928-7fd6d6521c35 System.Exception: Server returned a non successful status code - HTTPStatusCode=Unauthorized - Reason=Unauthorized - Content={"response":{"error_code":"110","error":"Invalid user name or password","ip":"142.0.201.228","domain":"xxxxxx.amocrm.com","server_time":1627006750}} at CrmIntegration.ScenarioProcessorBase.ProcessRequest(ScenarioRequest request, IValueManager customManager, HttpClient client, CancellationToken token) at CrmIntegration.ScenarioProcessorBase.ProcessScenario(ProtocolScenario scenario, IValueManager customManager, CancellationToken token) at CrmIntegration.ScenarioProcessorBase.Execute(ProtocolScenario scenario, CancellationToken token) at CrmIntegration.ScenarioAuthHttpClientProvider.PerformScenarioIfNeeded(CancellationToken token) at CrmIntegration.ScenarioAuthHttpClientProvider.Create(CancellationToken token) at CrmIntegration.ScenarioProcessorBase.ProcessScenario(ProtocolScenario scenario, IValueManager customManager, CancellationToken token) at CrmIntegration.ScenarioProcessorBase.Execute(ProtocolScenario scenario, CancellationToken token) at CrmIntegration.CrmProcessor.GetContactInfoFromCrm(String contactNumber, Boolean isInboundCall, String destinationEmail, Boolean createIfNotFound, CancellationToken token)

 

[Vanlon]

So looking into this more, it appears that amoCRM has upgraded to oAuth 2.0 and 3cx has not updated their implementation. Does anyone know how to work around this?

 

[Evolute IT]

So looking into this more, it appears that amoCRM has upgraded to oAuth 2.0 and 3cx has not updated their implementation. Does anyone know how to work around this?

Check if a new version of the template is available. Some CRMs are not built-in anymore and you must download the template from the 3CX website.

https://www.3cx.com/docs/amocrm-pbx-integration/#h.kamm29jlahfc , step 1.

 

[edossantos]

We are aware of the upgrade to OAuth2 on the amocrm side. However, they are using a variation of OAuth2 that prevents us from properly implementing it. Let me explain the details. This is how OAuth2 authorization works:

1. 3CX launches the "authorization" endpoint, which is a page in the CRM, where you can enter your credentials and grant access.
2. Once you grant access, the CRM redirects the browser to a 3CX page providing an authorization code.
3. Then 3CX uses the authorization code to get a refresh token in the "token" endpoint of the CRM. This refresh token is stored in 3CX.
4. When we need to invoke an API, we need an access token. We use the refresh token obtained in the previous step to get an access token, which has a limited lifetime. When the access token expires, we use the refresh token again to get another access token.

The problem is that amocrm invalidates the original refresh token when it returns an access token, returning also a new refresh token. This is problematic, not only for 3CX, but for any client application, and no other CRM does this, not even Salesforce or Dynamics, because they know that this causes problems. What's the problem with this?

1. Particularly for 3CX this is a problem because we use the API from different modules (the System Service for calls, the Management Console for Live Chat, the Gateway Service for SMS). If one module gets an access token, it invalidates the token that other modules have in memory, causing errors on other modules.
2. If there is a network error, and 3CX doesn't get the response from the CRM, the token would not be updated on the 3CX side, but old tokens are invalidated on the CRM side, so the integration would stop working from this point onwards, until you manually go to the 3CX console and run the authorization flow again. This is not only a problem for 3CX, this could eventually affect any client application, and it's the main reason why no other CRM implements this variation of the OAuth2 flow.

As a consequence, we're unable to implement OAuth2 for amocrm. We keep the old template for existing users that have the API key enabled in their dashboards, but we know that this is not the case for new users, so there is no way to integrate with amocrm for new users. Unfortunately, this is out of our hands, and we can't provide a solution.

 

[Evolute IT]

We are aware of the upgrade to OAuth2 on the amocrm side. However, they are using a variation of OAuth2 that prevents us from properly implementing it. Let me explain the details. This is how OAuth2 authorization works:

1. 3CX launches the "authorization" endpoint, which is a page in the CRM, where you can enter your credentials and grant access.
2. Once you grant access, the CRM redirects the browser to a 3CX page providing an authorization code.
3. Then 3CX uses the authorization code to get a refresh token in the "token" endpoint of the CRM. This refresh token is stored in 3CX.
4. When we need to invoke an API, we need an access token. We use the refresh token obtained in the previous step to get an access token, which has a limited lifetime. When the access token expires, we use the refresh token again to get another access token.

The problem is that amocrm invalidates the original refresh token when it returns an access token, returning also a new refresh token. This is problematic, not only for 3CX, but for any client application, and no other CRM does this, not even Salesforce or Dynamics, because they know that this causes problems. What's the problem with this?

1. Particularly for 3CX this is a problem because we use the API from different modules (the System Service for calls, the Management Console for Live Chat, the Gateway Service for SMS). If one module gets an access token, it invalidates the token that other modules have in memory, causing errors on other modules.
2. If there is a network error, and 3CX doesn't get the response from the CRM, the token would not be updated on the 3CX side, but old tokens are invalidated on the CRM side, so the integration would stop working from this point onwards, until you manually go to the 3CX console and run the authorization flow again. This is not only a problem for 3CX, this could eventually affect any client application, and it's the main reason why no other CRM implements this variation of the OAuth2 flow.

As a consequence, we're unable to implement OAuth2 for amocrm. We keep the old template for existing users that have the API key enabled in their dashboards, but we know that this is not the case for new users, so there is no way to integrate with amocrm for new users. Unfortunately, this is out of our hands, and we can't provide a solution.

Wow, this is the stupidest way of doing OAuth I've ever seen.