Webhook в AmoCRM — это HTTP-запрос, который система отправляет на внешний URL в момент, когда что-то происходит: создалась сделка, сменился статус, пришёл новый контакт. Настраивается через раздел «Настройки → Интеграции → Webhooks». Указываете URL назначения, выбираете события — и AmoCRM начинает слать данные туда сам, без вашего участия. Никакого polling, никаких «а давайте раз в минуту спрашивать, что изменилось». Просто: событие случилось — запрос ушёл.
Это самый прямой способ подружить CRM с чем угодно — телефонией, складом, своей базой данных, Telegram-ботом, Google Sheets через Apps Script. Главное — чтобы на другом конце кто-то слушал.
Где это вообще находится и как включить
Идёте в AmoCRM, левое меню — шестерёнка (Настройки), дальше «Интеграции». Там будет раздел «Webhooks». Нажимаете «Добавить хук», вставляете URL, ставите галочки на нужные события.
Список событий приличный:
- добавление/изменение/удаление сделки
- смена статуса сделки
- добавление контакта или компании
- входящий/исходящий звонок
- добавление примечания
- смена ответственного
Можно вешать несколько URL на одно событие. Или один URL на десяток событий — зависит от архитектуры на принимающей стороне.
Данные летят в формате POST, application/x-www-form-urlencoded. Не JSON. Это момент, который регулярно ломает людей — они ждут JSON, получают form-data, смотрят в логах кашу и думают, что AmoCRM сломалась.
Три реальных кейса — где это работает и где нет
Кейс 1. Интеграция с IP-телефонией (Sipuni), ниша — юридические услуги. Нужно было при входящем звонке автоматически создавать сделку и прикреплять запись разговора. Sipuni умеет слать вебхуки в AmoCRM — всё звучит просто. На деле потратили 3 дня на то, что запись разговора прицеплялась к сделке раньше, чем сделка успевала создаться. Гонка событий. Решили задержкой в 4 секунды на стороне Sipuni — колхоз, но работает уже 8 месяцев без проблем.
Кейс 2. Передача данных в складскую систему (1С), производство мебели. При смене статуса сделки на «Счёт выставлен» — вебхук летит на самописный PHP-скрипт, тот парсит данные и создаёт заказ в 1С. Работает. Но один раз 1С упала на 40 минут — AmoCRM слала хуки, скрипт их не принимал, данные потерялись. 11 заказов пришлось восстанавливать вручную. После этого добавили очередь (RabbitMQ) и retry-логику. Цена вопроса — примерно 23 000 ₽ на доработку. Зато теперь не теряем ничего.
Кейс 3. Уведомления в Telegram, онлайн-школа. Руководитель отдела продаж хотел получать сообщение в Telegram каждый раз, когда сделка зависает на этапе «Думает» больше 2 дней. Вебхуки тут не помогут напрямую — они реагируют на события, а не на их отсутствие. Попытались скрутить через триггер в Digital Pipeline + вебхук на бота. Сработало, но с задержкой до 6 часов в пике. Переделали на отдельный cron-скрипт, который сам опрашивает API AmoCRM раз в час. Иногда правильный инструмент — не вебхук.
Что реально ломается при настройке
Первое и самое частое — принимающий сервер не отвечает 200 OK за отведённое время. AmoCRM ждёт ответа, не получает — считает хук неудавшимся. Повторов нет. Данные ушли в никуда. Поэтому принимающий скрипт должен сначала ответить 200, потом уже обрабатывать данные — не наоборот.
Второе — SSL. Если у вас на сервере протухший или самоподписанный сертификат, AmoCRM просто не будет слать запросы. Без объяснений. Проверяйте через curl с флагом --verbose.
Третье — кодировка. Данные в form-data, ключи вложенные типа leads[add][0][id]. В PHP это разбирается автоматически через $_POST. В Python или Node.js придётся парсить вручную или использовать библиотеки.
Хотя нет, с Python тут я слегка упростил — библиотека requests нормально разворачивает form-data, проблема обычно в том, как люди читают вложенные массивы после парсинга.
Как проверить, что хук долетает
Самый быстрый способ — webhook.site. Заходите, получаете временный URL, вставляете его в AmoCRM, генерируете событие (создайте тестовую сделку), смотрите что пришло. Занимает 3 минуты. Делайте это всегда перед тем, как прикручивать реальный обработчик — сразу видно структуру данных, поля, вложенность.
Ещё можно RequestBin. Суть та же.
В самой AmoCRM логов отправленных вебхуков нет. Это неудобно — вы не можете зайти и посмотреть «а этот хук вообще ушёл?». Поэтому логирование на принимающей стороне — не опция, а необходимость. Пишите в файл или базу хотя бы timestamp и первые 500 символов тела запроса.
Вопросы, которые задают чаще всего
Можно ли отправить вебхук из AmoCRM в локальную сеть (интранет)? Нет. URL должен быть доступен из интернета. Если сервер внутри корпоративной сети — нужен публичный прокси или туннель (ngrok для тестов, нормальный реверс-прокси для продакшна).
Сколько вебхуков можно добавить? По документации — до 100 на аккаунт. На практике больше 10–15 редко нужно. Если у вас их 30 — скорее всего, архитектуру стоит пересмотреть.
AmoCRM повторяет хук, если он не доставлен? Нет. Retry нет. Если принимающий сервер упал — данные теряются. Строить на этом что-то критичное без буфера на принимающей стороне — рискованно.
Как авторизовать входящий запрос — убедиться, что он реально от AmoCRM? В AmoCRM нет встроенной подписи для вебхуков (в отличие от, например, Stripe). Проверяйте по IP-адресам AmoCRM или добавляйте в URL секретный токен — например, https://myserver.com/webhook?token=abc123. Не идеально, но рабочий минимум.
Вебхуки работают на всех тарифах AmoCRM? Да, на всех платных. На пробном периоде тоже работают.
Один момент, который упускают почти все
Когда настраиваете вебхук на «изменение сделки» — он срабатывает буквально на любое изменение. Поменяли тег, добавили примечание, кто-то открыл карточку и автоматом что-то обновилось — хук улетел. На нагруженных аккаунтах это десятки запросов в минуту. Принимающий сервер должен быть готов к такой нагрузке, и в обработчике нужно чётко фильтровать — смотреть, что именно изменилось, и реагировать только на нужное поле или статус.
Один клиент из e-commerce поймал это на себе: их сервер получал 2 300–2 700 запросов в час в пиковые дни, хотя реально значимых событий было от силы 80–90. Сервер справлялся, но деньги на хостинг выросли примерно в 2,3 раза. После добавления фильтрации в обработчик — нагрузка упала до нормы за неделю.
Вебхуки — инструмент прямой и быстрый. Но «быстро настроить» и «настроить правильно» — это два разных проекта.
