Expand capabilities with API
We strive to provide maximum opportunities for integration of amoCRM with other services and systems so that you, our clients and partners, could expand the opportunities of amoCRM for yourself and for other users (both yours and ours).
Writing your own widgets is not so difficult as it may seem at first. In order to make a developer’s life even easier, besides instructions, we also provide examples of using methods and have written a library for agile PHP-development.
Also, you can use the console to try working with API and test queries through an independent service.
What is widget?
If you only need to exchange data between amoCRM and external systems, then you can use REST API. This will allow you to receive, add and refresh data in amoCRM remotely.
In case your solution must be available to all clients of amoCRM, or you need to involve JS, interact with users within your browser and supplement system interfaces, all these capabilities are provided by widget system.
A widget is an array of settings, JS and PHP files, which can be added to any amoCRM account, when a client turns on a widget.
Practical examples of using widgets:
- I want to output additional information about the contact (in the contact card) from my internal accounting system;
- I want to provide employees of my company with an ability to send a request to the accounting department to form a payment document directly from the lead card;
- I am a developer of an external service (telephony, direct e-mail), and I want to provide amoCRM clients with an ability to use my service by publishing a public widget and making integration easier and more transparent.
|Widget / Add-on||An additional component for the system, which can be turned on and customized by the user for his account in order to extend functionality of amoCRM. A widget may contain JS file, settings file, PHP file, and images used in add-on's operation.|
|Languages / Localization||amoCRM is available in English.|
|Manifest||A file, which must be uploaded with a widget, containing widget description and settings.|
|Widget settings||Some widgets require to input settings during installation, e.g. account name in the external system, authorization parameters for this system, field settings, etc.|
|Account||A company’s amoCRM profile containing its payment details, billing information, proprietary data and the list of users, which will have access to these data. Each account has a subdomain in the system, e.g. company.amocrm.com|
General rules of working with API
All communication with API is performed in encrypted form through the SSL protocol. It means that all links to API must contain the HTTPS protocol. It is particularly important to remember this fact in case of accessing through JS, when you are accessing some external resources, for example, WebSocket. Within the system, the user is always connected securely, and any attempt to access an HTTP image will be blocked, or the user’s browser will show a warning message.
It's strongly recommened to renew your API-key (hash) from time to time. If key wasn't updated within six month, system keeps rights to do this automatically
All requests must be addressed not to the general domain http://www.amocrm.com, but to the exact address of your account, for example, https://company.amocrm.com or https://example.amocrm.com.
Mechanisms for limiting the activity of working with API are provided – no more than one request per second. Also, some methods provide limitations on the amount of returned data for each data request (for more details, please, refer to descriptions of specific methods).
In case the limit of the number of requests is exceeded, an error HTTP 429 will be returned. If the limit is exceeded repeatedly, account will be blocked and HTTP 403 will be returned on any request.
In case of subscription expire for more than 30 days, access to data via API will be blocked. HTTP 402 will be returned on any request.
In order to work with our API, it is required the support one of the following cryptographic protocols: TLS 1.1, TLS 1.2
The recommended version is TLS 1.2
Since 11/16/2016 we will no longer support the SSLv3 protocol, due to the fact that this protocol is considered to be vulnerable.
cURL library supports protocol TLS 1.1 / 1.2, since version 7.34.0. You can explicitly specify the version of the protocol in cURL session parameters: