Вебхук простыми словами: как системы сами сообщают друг другу о событиях и что может пойти не так

Короткий ответ: вебхук — это способ, которым одна система сама сообщает другой, что у неё произошло событие: прошла оплата, сделка перешла на новый этап, пришла заявка. Вместо того чтобы каждые пять минут спрашивать «есть новости?», ваша программа получает короткое сообщение на заранее указанный адрес. Это быстро и экономно, но у вебхука есть слабое место: если в момент отправки ваш сервер не ответил, событие может потеряться. Поэтому рабочая связка на вебхуках — это не только «адрес вставили в настройки», но и журнал, повторная обработка, защита адреса и сверка.

Что такое вебхук на бытовом примере?

Представьте, что вы ждёте посылку. Можно каждый час звонить в пункт выдачи и спрашивать, пришла ли она, — это опрос. А можно оставить номер, и вам пришлют СМС, когда посылка приедет, — это вебхук. Источник события сам сообщает о нём, а вы оставляете ему «номер» — адрес, куда стучаться.

Технически вебхук — обычный HTTP-запрос. Система, где случилось событие, отправляет на ваш адрес (например, https://api.vasha-kompaniya.ru/hooks/oplata) небольшой пакет данных: что произошло, с каким объектом, когда. Ваш сервер принимает пакет, отвечает «получил» и дальше делает с ним что нужно.

Три типичные сцены, где это работает каждый день:

• «Оплата прошла». Платёжный сервис сообщает сайту, что платёж по заказу 1042 успешен. Сайт меняет статус заказа, отправляет чек и письмо клиенту.
• «Сделка сменила этап». Менеджер в CRM перетащил сделку в колонку «Договор подписан». CRM отправляет вебхук, и где-то создаётся счёт, задача юристу или сообщение в рабочий чат.
• «Пришла заявка». Сервис форм, квизов или рекламный кабинет передаёт новую заявку в CRM или в канал отдела продаж через несколько секунд после отправки.

Важная деталь: вебхук — это уведомление, а не полный обмен. Часто в нём приходит только номер объекта и тип события, а подробности ваша система потом запрашивает сама по API.

Чем вебхук отличается от запроса по API?

Направлением. По API ваша программа сама идёт в другую систему и спрашивает или меняет данные, когда ей нужно. Вебхук — обратный путь: другая система приходит к вам, когда событие уже случилось. API — «позвонить самому», вебхук — «вам перезвонят».

Что такое API и как устроена интеграция в целом, мы разбирали в статье «Интеграция по API: что это и сколько стоит». Здесь важно понять, почему одного API часто мало. Если CRM не умеет сообщать о событиях, вашей программе остаётся опрос: раз в несколько минут запрашивать список изменившихся сделок. Это работает, но с задержкой, тратит лимиты запросов и легко пропускает изменения между запусками.

На практике хорошая интеграция использует оба способа: вебхук как сигнал «что-то изменилось» и API как источник точных данных. Получили событие «оплата прошла» — сходили по API и проверили, что платёж действительно в статусе «успешен» и сумма совпадает с заказом.

	Опрос по API	Вебхук
Кто начинает	Ваша система раз в N минут спрашивает: «Что нового?»	Источник сам присылает событие на ваш адрес
Скорость реакции	Не быстрее интервала опроса	Секунды после события
Нагрузка	Много пустых запросов, легко упереться в лимиты	Запрос только когда что-то случилось
Что нужно с вашей стороны	Только исходящий доступ в интернет	Публичный HTTPS-адрес, который всегда отвечает
Если ваш сервер лежал час	Догонит при следующем опросе	Зависит от отправителя: повторит, отложит или потеряет
Типичная поломка	Опрос пропускает изменения между запусками	События молча пропадают, пока никто не заметит

Где бизнес сталкивается с вебхуками?

Почти в любой связке облачных сервисов: CRM, платёжные системы, сервисы рассылок, телефония, боты, маркетплейсы, конструкторы форм и автоматизаций. Если в настройках сервиса есть поле «URL для уведомлений» или раздел «Вебхуки», это оно.

• CRM. В amoCRM вебхук подписывают на события — добавление или изменение сделки, контакта, задачи. В Битрикс24 есть два вида: входящий (ваша программа обращается к CRM по секретному адресу) и исходящий (CRM сама сообщает о событии). Названия похожи, а смысл противоположный — это частая путаница при постановке задачи.
• Платёжные сервисы. Уведомление об оплате, возврате, отмене приходит вебхуком. Именно по нему сайт узнаёт, что деньги поступили, даже если покупатель закрыл вкладку, не дождавшись возврата на страницу «Спасибо». Подробнее о приёме оплаты — в статье «Приём оплаты на сайте и онлайн-касса».
• Боты. Telegram может присылать сообщения пользователей боту вебхуком на адрес сервера, где бот работает. Чем вебхук отличается от polling и где держать бота, мы разбирали в статье «Где разместить Telegram-бота».
• Конструкторы автоматизаций. В n8n, Make и аналогах сценарий часто начинается с блока «Webhook» — он выдаёт адрес, на который другая система шлёт события. Когда этих конструкторов достаточно, мы разбирали в статье «n8n и Make простыми словами».
• Внутренние системы. Мониторинг, система сборки или форма на сайте пишут в рабочий мессенджер сами. Например, в корпоративном мессенджере «Гонец» есть входящие вебхуки: у системы свой адрес, а сообщения в канал приходят от имени бота.

Почему вебхуки теряются и как это ловить?

Потому что вебхук отправляют один раз «здесь и сейчас». Если ваш сервер в эту секунду перезагружался, ответил слишком медленно или с ошибкой, дальше всё зависит от правил отправителя: одни повторят несколько раз, другие запишут сбой и забудут. Узнаёте вы об этом обычно от клиента.

Правила повтора у сервисов сильно различаются, и их стоит проверить в документации каждой системы до старта. Несколько примеров по официальной документации на октябрь 2026 года:

• amoCRM ждёт ответ не дольше 2 секунд. Если ответа нет или он с ошибкой, отправка повторяется через 5 минут, затем через 15 минут; если ваш сервер отвечает ошибкой 5xx, будут ещё две попытки — через 15 минут и через час. Успешным считается любой ответ с кодом от 100 до 299. Если за последние 2 часа набралось больше 100 невалидных ответов и последний тоже неудачный, вебхук отключается — администратор видит уведомление и включает его вручную.
• Битрикс24 для исходящих вебхуков, по документации событий, фиксирует сбой, но событие повторно не отправляет. Забрать пропущенное из очереди можно только при подписке через приложение — механизм офлайн-событий.
• ЮKassa повторяет уведомление в течение 24 часов с момента события, пока не получит ответ 200.

Отсюда главные причины потерь в реальных проектах:

1. Долгая обработка в момент приёма. Сервер получает вебхук и тут же идёт в 1С, CRM и почту, а отвечает «получил» только в конце. Две секунды прошли — отправитель считает доставку неудачной. Правильно: сначала сохранить событие и ответить, потом обрабатывать.
2. Повторы без защиты от дублей. Отправитель повторил запрос, потому что не дождался ответа, а ваш сервер обработал оба. Итог — два счёта, два письма, двойное списание бонусов. Каждое событие нужно узнавать по номеру и обрабатывать один раз.
3. Недоступность сервера. Обновление, переезд хостинга, истёкший сертификат, сменившийся адрес. Вебхук продолжает стучаться в старое место.
4. Вебхук отключили. Сама система после серии ошибок, администратор при «наведении порядка» или вместе с учётной записью уволенного сотрудника.
5. Порядок событий. «Сделка изменена» может прийти раньше «сделка создана». Если код этого не ждёт, данные перезаписываются старыми.

Как это ловят на практике:

• Журнал входящих событий. Каждый пришедший вебхук записывается целиком, с временем и результатом обработки. Без журнала на вопрос «почему заказ не попал в 1С» ответа нет.
• Очередь и повторная обработка. Если внутренняя обработка упала, событие остаётся в очереди и повторяется, а не исчезает.
• Сверка по расписанию. Раз в час или раз в сутки программа запрашивает по API список изменений и сравнивает с полученными событиями. Это страховка именно для систем, которые не повторяют отправку.
• Оповещение о тишине. Если за рабочий день не пришло ни одного события об оплате, хотя обычно их десятки, ответственный получает сообщение. Тишина — тоже сигнал.

Сервис	Что делает, если ваш сервер не ответил	Как проверить подлинность
amoCRM	Ждёт ответа до 2 секунд; при ошибке повторяет через 5 и 15 минут, а при ошибках сервера (5xx) — ещё через 15 минут и через час; при массовых ошибках отключает вебхук	Проверять данные встречным запросом по API
Битрикс24 (исходящий вебхук)	Фиксирует сбой, но событие повторно не отправляет	Сверять application_token из запроса
ЮKassa	Повторяет уведомление 24 часа с момента события, пока не получит ответ 200; адрес — только HTTPS на порту 443 или 8443	Проверять IP отправителя и статус платежа по API
Telegram-бот	Повторяет запрос ограниченное число раз	Сверять секретный токен в заголовке запроса

Как защитить адрес вебхука?

Адрес вебхука — это дверь в вашу систему. Если кто-то узнает его и отправит поддельное «оплата прошла», а сервер поверит, товар уйдёт бесплатно. Поэтому каждое событие нужно проверять: пришло ли оно от того, от кого должно, и совпадает ли с реальным состоянием дел.

Способы проверки зависят от отправителя, и обычно их сочетают:

• Секретный токен или подпись. Отправитель кладёт в запрос заранее известный секрет или подпись содержимого. Битрикс24 передаёт application_token, Telegram — токен в заголовке X-Telegram-Bot-Api-Secret-Token, если его задали при установке вебхука. Запросы без правильного секрета отклоняются.
• Проверка адреса отправителя. Некоторые сервисы публикуют список своих IP-адресов, например ЮKassa. Запрос с другого адреса — подозрительный.
• Встречная проверка по API. Самый надёжный способ для денег: получив уведомление об оплате, сервер сам спрашивает платёжный сервис о статусе и сумме. Поддельный вебхук эту проверку не пройдёт.
• Только HTTPS. Без шифрования данные клиентов и токены видны по дороге. Многие сервисы и не разрешают адрес без HTTPS: например, ЮKassa принимает только HTTPS-адрес на порту 443 или 8443 с TLS не ниже 1.2.
• Секретные адреса не в коде страницы. Входящий вебхук Битрикс24 содержит ключ доступа прямо в адресе. Если вставить его в код формы на сайте, любой посетитель сможет писать в вашу CRM. Обращаться к такому адресу должен только сервер.
• Привязка к служебной учётной записи. Вебхук, настроенный от имени конкретного менеджера, перестанет работать, когда того уволят или урежут права. Для интеграций заводят отдельного технического пользователя.

Когда вебхука нет или он не нужен?

Не у всех систем есть вебхуки: старая учётная программа, самописная база, некоторые отраслевые сервисы умеют только отвечать на запросы. И не всегда нужна мгновенная реакция: отчёту, который смотрят раз в неделю, хватит выгрузки по расписанию.

Варианты, когда вебхука нет:

• Опрос по API. Раз в несколько минут спрашивать «что изменилось с прошлого раза». Задержка есть, но для остатков или статусов доставки её часто достаточно.
• Обмен файлами по расписанию. Для 1С это нередко штатный путь: выгрузка и загрузка в согласованном формате.
• Уведомление на почту, которую читает программа. Не элегантно, но иногда это единственное, что умеет система. Такой путь хрупкий, его стоит считать временным.

Вебхук вам, скорее всего, не нужен, если событий единицы в день, менеджер всё равно смотрит их глазами, а задержка в час никого не беспокоит. И наоборот: он почти обязателен, когда от скорости реакции зависят деньги или клиент — оплата, заявка, запись, отмена.

Что спросить у подрядчика перед заказом связки на вебхуках?

Спросите, что будет при сбое, дублях и поддельном запросе, и кто узнает о тишине. По ответам подрядчика видно, построит ли он обмен, который переживёт первую же поломку, или просто вставит адрес в настройки.

1. Какие события и от каких систем мы получаем, что отправитель делает при сбое — повторяет или нет?
2. Где будет журнал входящих событий, сколько он хранится и кто из наших сотрудников может его смотреть?
3. Что произойдёт, если одно и то же событие придёт дважды? Как защищаемся от дублей?
4. Как сервер проверяет, что запрос пришёл от настоящего отправителя? Есть ли встречная проверка для оплат?
5. Есть ли сверка по расписанию для систем, которые не повторяют отправку?
6. Кто и как узнает, что вебхуки перестали приходить, — до того как позвонит клиент?
7. На чью учётную запись настроены вебхуки и ключи, где они хранятся и как их сменить без остановки обмена?
8. Где описано, как работает обмен и что делать при сбое, — будет ли инструкция?

В тарифе «Интеграции и автоматизация» мы закладываем это по умолчанию: связка до двух систем через API или вебхуки, обработка ошибок обмена и журнал операций, проверка на реальных данных перед запуском и инструкция о том, что делать при сбое. Цена — от 32 000 ₽, срок — от 2 дней; каждая система сверх двух оценивается отдельно. После запуска 7 дней бесплатно вносим мелкие правки, гарантия по договору — 30 дней, дальше — поддержка от 7 900 ₽ в месяц.

Какие ошибки чаще всего допускают с вебхуками?

Самые дорогие ошибки — не в коде, а в постановке: вебхук считают надёжной доставкой, не ведут журнал и не назначают ответственного. Пока обмен работает, это незаметно, но первая же потеря обнаруживается через недовольного клиента.

• Верить вебхуку на слово. Отгружать товар по факту пришедшего «оплачено» без встречной проверки.
• Делать всё в момент приёма. Тяжёлая обработка до ответа отправителю приводит к таймаутам, повторам и дублям.
• Тестировать только «счастливый путь». Проверили, что заявка доходит, но не проверили, что будет при выключенном сервере, двойной отправке и событиях не по порядку.
• Путать входящий и исходящий вебхук. Особенно в Битрикс24, где оба называются вебхуками, но работают в разные стороны.
• Привязать всё к личному аккаунту. Вебхуки и ключи на учётной записи разработчика или менеджера, которого потом нет.
• Забыть про лимиты. На каждое событие — несколько встречных запросов по API, и в пиковый час интеграция упирается в ограничения системы.

Если вы видите у себя хотя бы два пункта из списка, обмен стоит проверить до того, как на него ляжет рекламная кампания или сезон продаж. Как устроена передача заявок в amoCRM и Битрикс24 и где там теряются данные, мы отдельно разбирали в статье «Заявки с сайта в amoCRM и Битрикс24».

Короткие ответы на частые вопросы

Чем вебхук отличается от API?

API — это набор действий, которые ваша программа может запросить у другой системы, когда сама захочет. Вебхук — обратное направление: система сама отправляет вам короткое сообщение, когда у неё что-то произошло. В рабочей интеграции обычно используют оба способа вместе.

Есть ли вебхуки в amoCRM и Битрикс24?

Да. В amoCRM вебхук подписывают на события вроде смены этапа сделки, в Битрикс24 есть исходящие вебхуки на события CRM и входящие — для запросов в CRM. Ведут они себя при сбоях по-разному: amoCRM повторяет отправку, исходящий вебхук Битрикс24 — нет.

Почему вебхук не приходит?

Чаще всего — ваш сервер не ответил вовремя или ответил ошибкой, сменился адрес или истёк сертификат, вебхук отключила сама система после серии ошибок, либо уволили сотрудника, на чьи права он был настроен. Первое, что стоит смотреть, — журнал входящих запросов на вашей стороне.

Можно ли настроить вебхук без программиста?

Отправить вебхук в конструктор автоматизаций или в мессенджер можно и без кода, если у обеих сторон есть готовые настройки. Программист нужен, когда событие надо проверить, разобрать, записать в учётную систему и не потерять при сбое.

Сколько стоит настроить обмен через вебхуки?

В Roboweb это тариф «Интеграции и автоматизация»: от 32 000 ₽, от 2 дней за связку до двух систем через API или вебхуки, с обработкой ошибок и журналом операций. Точную цену и срок фиксируем в договоре после разбора ваших систем.

Услуги и кейсы по теме: интеграция с 1С и CRM от 32 000 ₽ · кейс «Гонец» · цены и сроки