По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Основная цель API у CRM систем – это возможность дополнительных интеграций и надстроек. В Амо уже встроены десятки виджетов, которые позволяют расширить набор инструментов для отдела продаж, а так же собрать все необходимые сервисы в одном месте.
Разработчик видит AmoCRM как реляционную базу данных, доступ к которой получается через API запросы.
Авторизация
Работа с системой невозможна до того момента, как пользователь авторизуется в системе, используя логин и пароль. Использование системы с помощью API ничем не отличается в этом вопросе от пользовательского интерфейса. Методы API становятся доступными для работы только после авторизации.
URL метода - POST /private/api/auth.php
Аккаунт
Это рабочее пространство CRM-системы. С помощью запросов API можно получить информацию о сотрудниках, прикрепленных к аккаунту, оплаченной лицензии, настройках полей сделок и базе клиентов.
URL метода - GET /api/v2/account
Просмотрите фрагмент запроса:
Контакт
Это один из важнейших и основных элементов системы. Технически – это объект, состоящий из некоторого набора параметров (полей), которые ему задал администратор. Контакты могут быть прикреплены к одной или нескольким сделкам, но не могут принадлежать нескольким компаниям. Уникальными идентификаторами контактов являются такие данные как номер телефона или e-mail. В карточке контакта привязаны события, такие как новое письмо или звонок.
Добавление и обновление контакта происходит с помощью метода POST /api/v2/contacts
С помощью метода GET /api/v2/contacts/ можно вызвать список контактов с возможностью фильтровать данные в нем.
Так, например, будет выглядеть запрос на обновление контакта:
Сделка
Ещё один важный элемент в CRM-системе. Её конфигурация так же зависит от полей, установленных администратором. К сделке могут быть прикреплены контакты, а могут и отсутствовать вовсе. Элементу в обязательном порядке должен быть присвоен статус, который чаще всего совпадает с этапом воронки, где находится в данный момент сделка.
Метод позволяют добавлять сделки и обновлять данные внутри них - POST /api/v2/leads
Компания
Совпадает по своему значению с элементом «Контакт». Управлять «Компанией» можно с помощью метода - POST /api/v2/companies
Задача
Для задачи существует два необходимых параметра: дата и ответственный. При этом прикреплять задачу к сделке или контактам необязательно.
Событие
События – это дополнительная информация, которая вносится в карточку к контакту или сделке. Примером события можно назвать звонок в компанию, электронное письмо или пометку менеджера по продажам в карточке клиента. События не имеют обязательных полей или прикреплений. События часто используются виджетами, например, приложения телефонии самостоятельно могут использовать этот элемент для записи информации об исходящем или входящем звонке в карточке определенного клиента. События удобно рассматривать как логи, так как они расположены в хронологическом порядке.
Вебхуки
AmoCRM позволяет разработчикам интегрировать систему в сторонние сервисы с помощью вебхуков. Каждый из них может быть специально настроен для определенного сервиса. Чтобы настроить вебхуки самостоятельно, нужно сделать следующее:
Зайти в Настройки->Интеграции;
Выбрать Собственные интеграции + WebHooks;
Кликнуть «Добавить хук» ;
Ввести URL;
Отметить события, происходящие в системе, после которых нужно отправить уведомление;
Сохранить;
Amo ожидает ответа от хука в течение 2-х секунд, при 100 неудачных попытках получить ответ от сервера хук отключается, его можно подключить заново по тому же алгоритму.
Существует множество бесплатных и многофункциональных IP - софтфонов. В сегодняшней статье расскажем об одном из таких программных клиентов - Linphone и покажем, как подготовить его для использования вместе с IP-АТС Asterisk.
/p>
Теория
Linphone (Linux Phone) является кроссплатформенным решением для IP-телефонии, работающим по протоколу SIP, которое позволяет совершать аудио и видео звонки через Интернет.
Linphone доступен как в виде десктопных версий для операционных систем Microsoft Windows, Linux, Mac OS так и в виде мобильных приложений для устройств на базе операционных систем Android, iOS
Данный софтфон совместим и поддерживает следующие протоколы: SIP, SRTP, ZRTP, STUN, ipv6, обмен мгновенными текстовыми сообщениями по протоколу SIMPLE. Поддерживаются следующие типы аудиокодеков: G.711, GSM-FR, Speex, iLBC и видеокодеков: H.263, MPEG4, theora H.264
Настройка
Рассмотрим настройки софтфона Linphone для работы с IP-АТС Asterisk. Устанавливать будем клиент для операционной системы Windows. Для этого нужно сначала скачать дистрибутив с сайта разработчика linphone.org. Самая последняя версия – 3.10.2 от 13 августа 2016.
Затем нужно выполнить стандартную процедуру установки, согласившись со всеми лицензионными правилами и указав путь, куда необходимо установить программу.
В процессе установки, Вам предложат установить кодек Cisco H.264, рекомендуем согласиться с данным пунктом.
Когда установка будет завершена, Вам предложат создать учётную запись для совершения звонков по протоколу SIP. Нажимаем Forward
Далее нужно выбрать тип учётной записи. Доступно четыре варианта – создание учётной записи на сайте linphone.org, ввести аутентификационные данные ранее созданной учётной записи с сайта linphone.org, ввести учётные данные ранее созданной учётной записи SIP – нам подходит именно этот пункт, поскольку мы будем использовать учётные данные внутреннего номера , который создали ранее на нашей IP-АТС. И последний из доступных вариантов – указать URI удалённого сервера конфигурации. Итак, выбираем I have already a sip account and I just want to use it
И вводим учётные данные, которые мы уже создали ранее на нашей IP-АТС. Например номер 1021
А далее, просто переносим их в Linphone, 192.168.1.148 - это адрес нашей IP-АТС.
Если всё было сделано верно, то после регистрации напротив наших учётных данных мы увидим зеленый круг - Online, свидетельствующий о том, что наша учётная запись активна и можно совершать звонки при помощи клиента Linphone.
Седьмая часть тут.
Поля фиксированной длины - самый простой из описанных в словаре механизмов. Протокол определяет набор полей, какие данные содержит каждое поле и насколько велико каждое поле. Эта информация «встроена» в определение протокола, поэтому каждая реализация построена в соответствии с этими же спецификациями и, следовательно, может взаимодействовать друг с другом. Рисунок 1 иллюстрирует кодирование поля фиксированной длины, используемое в протоколе Open Shortest Path First (OSPF), взятом из RFC2328.
Ряд чисел в верхней части рисунка 1 указывает отдельные биты в формате пакета; каждая строка содержит 32 бита информации. Первые 8 битов указывают номер версии, вторые 8 битов всегда имеют номер 5, следующие 16 битов содержат общую длину пакета и так далее Каждое из этих полей дополнительно определяется в спецификации протокола с видом информации, переносимой в поле и как оно закодировано. Например:
Поле номера версии кодируется как целое число без знака. Это метаданные, указывающие словарь и грамматику, используемые для этого пакета. Если формат пакета необходимо изменить, номер версии может быть увеличен, что позволяет передатчикам и получателям использовать правильный словарь и грамматику при кодировании и декодировании информации в пакете
Число 5 указывает тип пакета в протоколе; это часть словаря, определенного в другом месте в документе стандартов, поэтому он просто вставляется как фиксированное значение на этом рисунке. Этот конкретный пакет является пакетом подтверждения состояния канала (Link State Acknowledgment Packet).
Длина пакета кодируется как целое число без знака, указывающее количество октетов (или наборов из 8 битов), содержащихся в полном пакете. Это позволяет размеру пакета варьироваться по длине в зависимости от объема передаваемой информации.
Формат поля фиксированной длины имеет несколько преимуществ. Прежде всего, местоположение любого фрагмента информации в пакете будет одинаковым для каждого пакета, что означает, что легко оптимизировать код, предназначенный для кодирования и декодирования информации вокруг формата пакета. Например, обычным способом обработки формата пакета фиксированной длины является создание структуры данных в памяти, точно соответствующей формату пакета; когда пакет считывается с провода, он просто копируется в эту структуру данных. Поля в пакете могут быть прочитаны напрямую.
Форматы фиксированной длины имеют тенденцию быть несколько компактными. Метаданные, необходимые для кодирования и декодирования данных, передаются «вне протокола» в форме спецификации протокола. Сами пакеты содержат только значение и никогда не содержат никакой информации о значениях. С другой стороны, форматы фиксированной длины могут тратить много места на буферизацию полей, чтобы они всегда были одинаковой длины. Например, десятичное число 1 может быть представлено одной двоичной цифрой (один бит), тогда как десятичное число 4 требует 3 двоичных цифры (три бита); если поле фиксированной длины должно быть в состоянии представить любое число от 0 до 4, оно должно быть длиной не менее 3 битов, даже если два из этих битов иногда «теряются» при представлении меньших десятичных чисел.
Форматы фиксированной длины также часто занимают место, выравнивая размеры полей по общим границам памяти процессора, чтобы повысить скорость обработки. Поле, которое должно принимать значения от 0 до 3, даже если для представления полного набора значений требуется только два бита, может быть закодировано как 8-битовое поле (полный октет), чтобы обеспечить всегда выравнивание следующего поля на границе октета для более быстрой обработки в памяти.
Гибкость - то, где кодирование фиксированной длины часто сталкивается с проблемами. Если какое-либо поле определено как 8-битное значение (один октет) в исходной спецификации, нет очевидного способа изменить длину поля для поддержки новых требований. Основной способ решения этой проблемы в схемах кодирования с фиксированной длиной - через номер версии. Если длина поля должна быть изменена, номер версии изменяется в форматах пакетов, поддерживающих новую длину поля. Это позволяет реализациям использовать старый формат, пока все устройства в сети не будут обновлены для поддержки нового формата; после того как все они обновлены, вся система может быть переключена на новый формат, будь то больше или меньше.