Вебхук — это способ обмена, при котором система сама сообщает вам о событии в момент, когда оно произошло: клиент оформил заказ, оплата прошла, статус сделки изменился. Вместо того чтобы регулярно спрашивать «есть ли что-то новое», вы один раз даёте адрес, на который нужно присылать уведомления, и дальше получаете их без запроса.
Объяснение «это обратный вызов» ничего не добавляет, поэтому сразу к практике. Подключить вебхук просто: часто это делается в настройках системы за один вечер. Сложность и деньги начинаются дальше — в том, что происходит, когда сообщение не дошло, дошло дважды или пришло не в том порядке. Именно эти три случая занимают почти всю смету, и именно их пропускают в дешёвых предложениях.
Дальше — модельные расчёты по состоянию на сентябрь 2026 года при ставке инженера 3 000 ₽/час. Про то, как устроен обмен целиком и почему API определяет цену интеграции, разобрано в соседнем материале; здесь — только про сообщения о событиях.
Звоним каждые пять минут или нам звонят сами
Есть два способа узнать, что заявка появилась. Первый — звонить и спрашивать: каждые пять минут ваша система обращается к чужой и получает ответ «нового нет». Это называется опросом. Второй — оставить номер и попросить перезвонить, когда что-то произойдёт. Это и есть вебхук.
Сообщение, которое одна система отправляет на заранее указанный адрес другой в момент наступления события. Бизнесу даёт скорость: заявка попадает менеджеру за секунды, а не в следующий цикл опроса. В смете — 8–20 часов сверх обычного обмена, потому что к вебхуку нужны приём, проверка подлинности и повтор при сбое. Проверочный вопрос: что произойдёт с событием, если наш сервер в этот момент недоступен?
Обратный подход: ваша система по расписанию сама спрашивает чужую, не появилось ли новых записей. Бизнесу это дешевле в разработке и надёжнее по природе — пропущенный цикл не теряет данные, следующий их заберёт. Плата — задержка, равная периоду опроса, и лишние обращения: при интервале в пять минут это 288 запросов в сутки на одну систему. Проверочный вопрос: какая задержка данных для нас приемлема на самом деле?
| Признак | Опрос по расписанию | Вебхук |
|---|---|---|
| Задержка | Равна интервалу: обычно 5–60 минут | Секунды |
| Что при недоступности приёмника | Ничего: следующий цикл заберёт всё пропущенное | Событие может потеряться, если нет очереди и повторов |
| Стоимость запуска | 8–14 часов, 24 000–42 000 ₽ | 24–32 часа, 72 000–96 000 ₽ |
| Лишняя нагрузка | 288 обращений в сутки на систему при интервале 5 минут | Ровно по числу событий |
| Когда выбирают | Поток до 50 событий в сутки, задержка терпима | Заявки, оплаты, статусы доставки — всё, где секунды стоят денег |
Две горизонтальные дорожки одна под другой. Верхняя подписана «Опрос по расписанию»: ряд из множества одинаковых мелких стрелок от левого блока «Наша система» к правому блоку «Чужая система», подпись под рядом «288 обращений в сутки, задержка до 5 минут». Нижняя подписана «Вебхук»: одна крупная стрелка в обратную сторону, от «Чужой системы» к «Нашей», с пометкой «событие» и подписью «доставка за секунды»; рядом с ней одна стрелка нарисована пунктиром и уходит мимо блока с подписью «не дошло — нужен повтор». Тонкие чертёжные линии, подписи по-русски.
Три сценария сбоя, ради которых берут деньги
Сеть ненадёжна, серверы перезагружаются, обновления выкатываются в рабочее время. Поэтому у любого обмена событиями есть три типовых поломки, и на каждую в нормальной смете стоит отдельная работа.
- 1Сообщение не дошло
Ваш приёмник был недоступен минуту, а система-отправитель за это время сообщила о трёх заказах. Лечится очередью и повторными попытками с нарастающим интервалом, плюс уведомление ответственному, когда попытки закончились. 6–10 часов работы. Важно: часть систем повторяет доставку сама, часть — нет; это первое, что надо выяснить в документации.
- 2Сообщение пришло дважды
Прямое следствие повторов: отправитель не получил подтверждение и прислал то же самое ещё раз. Без защиты один заказ превращается в два, а склад — в фантомные остатки. Лечится ключом операции и журналом принятых событий: система проверяет, что этот номер уже обрабатывался. 4–8 часов.
- 3Сообщения пришли не в том порядке
Событие «заказ отменён» обгоняет событие «заказ создан», и в CRM появляется отменённая сделка, которой не было. Лечится временем или версией события и правилом «более свежее состояние побеждает». 4–10 часов, и это работа, которую пропускают чаще всего — до первого спорного случая её отсутствие не видно.
Строка «настройка вебхука — 2–8 часов», которую вы видите в коммерческом предложении, покрывает первую позицию из семи. Это не обман, если рядом честно написано, что остальное не входит. Обманом это становится, когда такую строку подают как готовый обмен, а разницу обнаруживает бухгалтерия на сверке через квартал.
Почему вебхук не бывает единственным механизмом обмена
Главная неприятность вебхуков в том, что их потери молчаливы. Если опрос по расписанию не сработал, следующий цикл заберёт всё накопившееся — данные догонят сами. Если потерялось событие, его никто не хватится: система-отправитель считает, что сообщила, приёмник не знает, что был сигнал. Заявка просто не появляется, и узнают об этом от клиента через неделю.
Поэтому взрослая архитектура всегда двухслойная: вебхуки для скорости и сверочный проход по расписанию для полноты. Раз в час или раз в сутки система запрашивает список записей за период и сравнивает с тем, что у неё есть. Расхождения попадают в отчёт, а не в тишину. Эта строка в смете стоит около 18 000 ₽ и окупается первым же найденным расхождением.
Модельный расчёт для интернет-магазина: 3 000 событий в месяц, потеря 0,5 % — это 15 заявок. При конверсии 25 % и среднем чеке 18 000 ₽ упущено около 67 500 ₽ в месяц. Сверочный проход стоит 18 000 ₽ один раз. Именно поэтому вопрос «как мы узнаем, что за сутки ничего не потерялось» стоит задавать до подписания, а не после квартальной сверки.
Схема из двух горизонтальных дорожек между блоками «Система-источник» слева и «Наша система» справа. Верхняя дорожка подписана «быстрый слой»: стрелка «событие» ведёт в блок «Приём и проверка подлинности», далее в «Очередь и повтор», далее в «Проверка ключа операции», далее в «Запись». Нижняя дорожка подписана «медленный слой, раз в сутки»: стрелка «запрос списка за период» ведёт в блок «Сверка», от него две стрелки — «совпало» и «расхождение», вторая упирается в блок «Отчёт и уведомление ответственному». Внизу подпись: «сверочный проход — 18 000 ₽ один раз». Тонкие чертёжные линии, подписи по-русски.
Что превращает два часа работы в сорок
Разброс в оценке подключения вебхука — от двух часов до сорока — объясняется не квалификацией исполнителя, а пятью условиями. Все они выясняются до сметы.
| Условие | Добавка к работе | Почему |
|---|---|---|
| Один тип события, поля не меняем | 2–8 часов — базовый случай | Приняли, записали, ответили подтверждением |
| Пять типов событий с разными наборами полей | +8–14 часов | Каждый тип — своя проверка, свой маршрут и свой сценарий приёмки |
| Нужна гарантия, что ни одно событие не потеряно | +10–16 часов | Очередь, повторы, журнал принятых и сверочный проход |
| Приёмник внутри корпоративной сети | +4–10 часов | Нужен внешний адрес, белый список адресов отправителя, согласование с вашей службой безопасности |
| Проверка подписи и защита от подделки | +3–6 часов | Без неё на ваш адрес может прислать сообщение кто угодно |
Отдельная строка расходов — путаница в самом слове. В Битрикс24 «входящий вебхук» означает не уведомление о событии, а ключ-ссылку, по которой внешняя программа вызывает методы портала; уведомления наружу называются исходящими вебхуками. Два человека спокойно обсуждают «вебхук», имея в виду противоположные вещи, и выясняется это на демонстрации. Проверяйте направление словами: кто кому отправляет сообщение и по какому событию.
| Формулировка в предложении | Что за ней обычно стоит | Как раскрыть до подписания |
|---|---|---|
| «Настроим вебхуки» | Приём сообщения без очереди, повторов и сверки | Что произойдёт с событием, если наш сервер будет недоступен две минуты? |
| «Уведомления в реальном времени» | Направление и перечень событий не названы | Перечислите типы событий и укажите, кто кому их отправляет |
| «Всё будет синхронизироваться автоматически» | Сверочного прохода нет, расхождения ищутся вручную | Как мы узнаем, что за сутки ничего не потерялось? |
- 1Есть ли у системы-источника повторная доставка и сколько попыток она делает? Если повторов нет, очередь и сверка становятся обязательными, а не желательными.
- 2Где журнал принятых событий и как долго он хранится? Без журнала разбор спорного случая превращается в гадание.
- 3Как проверить, что за сутки ничего не потерялось? Правильный ответ — «есть отчёт сверки», а не «мы бы заметили».
- 4Проверяется ли подпись сообщения? Открытый адрес без проверки подлинности означает, что данные в вашу систему может прислать посторонний.
- 5Что вы покажете на приёмке? Сценарий из четырёх шагов ниже сотрудник выполняет сам, без программиста.
- Создайте тестовую запись в системе-источнике и убедитесь, что она появилась у приёмника за оговорённое время.
- Попросите отключить приёмник на две минуты, создайте ещё одну запись и включите обратно: запись должна доехать сама.
- Попросите отправить одно и то же событие дважды: вторая запись создаваться не должна.
- Откройте отчёт сверки за сутки: в нём должны быть число полученных событий и список расхождений, пусть даже пустой.
Когда вебхук не нужен
Вебхук покупают за скорость. Если скорость вам не нужна, вы платите лишние 54 000–72 000 ₽ за красивое слово в договоре. Проверьте себя по трём признакам, прежде чем соглашаться на эту строку.
- Поток меньше 50 событий в сутки и задержка в 15 минут никого не беспокоит. Опрос по расписанию обойдётся в 24 000–42 000 ₽ против 96 000 ₽ за полноценный приём событий, и сопровождать его проще: у него нет молчаливых потерь по природе.
- Данные нужны для отчётности, а не для действия. Если по событию никто не бежит звонить клиенту, разница между «через три секунды» и «через час» не стоит ничего.
- У системы-источника нет ни повторной доставки, ни подписи сообщений. В этом случае вебхук придётся страховать сверкой так плотно, что дешевле сразу строить обмен на опросе, а событиями пользоваться только как ускорителем.
И обратное правило, такое же честное: если вы обрабатываете заявки и первый ответ клиенту должен уходить в течение минуты, экономия на очереди и сверке обернётся потерянными обращениями. Про то, как распределяются заявки после приёма и во что обходится задержка на этом шаге, есть отдельное решение каталога, а термины, которые встретятся в смете рядом с вебхуком, собраны в словаре раздела.
Вебхук подключается за два часа. Тридцать оставшихся часов покупают ответ на один вопрос: как вы узнаете, что сегодня не потерялось ни одно сообщение.
