Webhooks или опрос по расписанию для обмена данными между системами

Webhook означает, что внешняя система сама сообщает вам о событии в момент, когда оно произошло, а опрос по расписанию (polling) означает, что вы сами регулярно спрашиваете, не появилось ли что-то новое. Webhooks дают быструю реакцию и меньше лишних запросов, опрос проще и предсказуемее. На практике надёжные интеграции часто используют оба способа вместе: webhook для скорости, опрос как страховку на случай пропусков.

Чем отличаются webhooks и polling на пальцах

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

Технически это выглядит так.

Webhook. Вы даёте внешней системе адрес вашего обработчика, например https://example.kz/hooks/orders. Когда случается событие (оплачен заказ, обновлён статус, создан документ), система отправляет на этот адрес HTTP-запрос с данными. Ваш обработчик принимает его, проверяет и сохраняет.

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

Оба способа решают одну задачу, но с разными компромиссами, и именно эти компромиссы определяют выбор.

Когда лучше работает webhook

Webhook выигрывает там, где важна скорость реакции и нет смысла делать частые пустые запросы.

• Мгновенные уведомления. Оплата прошла, и клиент должен сразу увидеть подтверждение, а менеджер получить сообщение.
• Редкие события. Если событий немного, постоянные запросы «ничего нового» просто тратят ресурсы и упираются в ограничения на число запросов.
• Внешняя система сама умеет отправлять. Многие платёжные сервисы и мессенджеры построены именно так.

Но у webhook есть свои требования к вам. Ваш сервер должен быть доступен из интернета по HTTPS, отвечать быстро и пережить всплески нагрузки. Если в момент отправки обработчик упал или был недоступен, событие может не дойти. Некоторые системы пробуют отправить повторно, другие нет, и поведение нужно уточнять в документации конкретного провайдера, а не предполагать.

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

Когда лучше работает опрос по расписанию

Polling уместен, когда внешняя система не умеет отправлять уведомления, когда ваша инфраструктура не может принимать входящие запросы или когда допустима небольшая задержка.

Плюсы очевидны. Вы контролируете момент обращения и нагрузку. Если ваш сервис был выключен, при следующем запуске он просто догонит пропущенное. Не нужно открывать адрес наружу, настраивать проверку подписи входящих запросов и защищаться от подделок.

Минусы тоже понятны. Между событием и вашей реакцией неизбежна задержка, равная интервалу опроса. Слишком частые запросы создают лишнюю нагрузку и могут упереться в лимиты чужого API. Слишком редкие дают ощутимое отставание.

Ключ к правильному polling — запрашивать только изменения, а не всё подряд. Для этого пользуются меткой времени последнего обновления или номером последней обработанной записи:

GET /api/orders?updated_since=2026-07-12T10:00:00Z&limit=100

Если API так не умеет, приходится сравнивать выгрузки целиком, а это дорого и медленно. Тогда стоит присмотреться к другим вариантам обмена.

Как сделать надёжный обработчик webhook

Если вы выбрали webhook, надёжность определяется несколькими решениями.

1. Отвечайте быстро. Сначала принять и сохранить запрос в очередь или таблицу, ответить кодом успеха, а тяжёлую обработку выполнить отдельно. Долгий ответ приводит к тайм-аутам и повторным отправкам.
2. Проверяйте подлинность. Принимайте запросы только с корректной подписью или секретом, если такая схема предусмотрена провайдером. Иначе любой может прислать вам поддельное «заказ оплачен». Конкретный способ подписи и заголовки берите из документации сервиса, не придумывайте свои.
3. Делайте обработку идемпотентной. Одно и то же событие может прийти дважды. Обработчик обязан дать тот же итог при повторе, а не создать второй заказ или второй платёж. Практика подробно разобрана в материале про повторные уведомления платёжных систем и идемпотентность.
4. Храните сырой запрос. Журнал входящих событий с телом, временем и результатом обработки экономит часы при разборе спорных ситуаций.
5. Учитывайте порядок. Не полагайтесь на хронологию прихода, сверяйтесь со временем события и текущим статусом объекта.

Минимальный каркас обработчика на PHP:

$body = file_get_contents('php://input');
// 1. проверить подпись по правилам провайдера
// 2. записать $body в таблицу incoming_events со статусом new
// 3. быстро ответить успехом
http_response_code(200);

А реальная обработка идёт отдельным процессом, который берёт записи со статусом new и переводит их в done или error.

Гибрид: webhook плюс сверка по расписанию

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

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

Для обмена в 1С схема та же: внешняя система присылает событие в HTTP-сервис 1С, а регламентное задание в 1С периодически доспрашивает недостающее. Как устроены такие сервисы, описано в разборе HTTP-сервисов в 1С.

Как выбрать, если вы сомневаетесь

Короткая памятка для решения:

• Внешняя система умеет webhooks и вам нужна реакция за секунды: берите webhook, но добавьте сверку.
• Внешняя система не отправляет уведомлений: опрос с метками последнего изменения.
• Ваш сервер недоступен снаружи или вы не хотите открывать вход: опрос.
• События редкие, но важные: webhook плюс редкая сверка.
• События частые и допустима задержка в минуты: опрос партиями бывает проще и устойчивее.
• Критичные деньги или учёт: гибрид обязателен.

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

Безопасность и ограничения на практике

Любой адрес, который принимает входящие запросы из интернета, привлекает внимание не только законных отправителей. Поэтому для webhook я всегда проверяю несколько вещей. Адрес должен работать только по HTTPS. Запрос должен проходить проверку подлинности в том виде, как её описывает провайдер: через подпись, секретный токен или ограничение по адресам отправителя, если такие данные публикуются. Лишние поля в запросе следует игнорировать, а не доверять им вслепую. Размер тела запроса стоит ограничить, чтобы обработчик не падал от больших вложений.

У polling свои ограничения. Большинство API задают лимиты на число запросов за период, и превышение приводит к временной блокировке. Если вы опрашиваете несколько систем, ведите счётчики и учитывайте ответы с кодом о превышении лимита: в таких случаях нужно сделать паузу, а не повторять запрос немедленно. Хорошей практикой считается нарастающая задержка между повторными попытками.

Не забывайте о часовых поясах и точности времени. Метка «изменено с» должна храниться в одном формате, лучше в UTC, и брать запас: запрашивайте чуть больший период, чем нужно, а дубли отсеивайте по идентификаторам. Это дешевле, чем потерять запись на границе интервала.

Пример схемы обмена между сайтом и учётной системой

Допустим, сайт принимает заказы, а учёт ведётся в отдельной системе. Рабочая схема выглядит так. Сайт при создании заказа записывает его в свою базу и ставит задачу на передачу. Фоновый процесс отправляет заказ в учётную систему по API и сохраняет внешний идентификатор. Когда в учётной системе меняется статус (собран, отправлен), она либо уведомляет сайт, либо сайт раз в несколько минут запрашивает изменения. Для надёжности раз в сутки запускается сверка: сравниваются числа заказов и сумм, расхождения попадают в отчёт.

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

Частые вопросы

Можно ли полностью положиться на webhooks?

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

Как часто надо опрашивать API?

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

Что делать с повторными вызовами одного webhook?

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

Нужен ли webhook, если у меня обычный сайт на хостинге?

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

Если вы планируете обмен данными между сайтом, учётной системой и сервисами и хотите продумать его надёжно, посмотрите страницу об автоматизации бизнеса или напишите в Telegram.