Webhook сообщает о событии: агенты проверяют отправителя, содержание и повторную доставку

Webhook, или вебхук, связывает событие в одном сервисе с вашим сайтом. Вы заранее указываете адрес приёмника. Когда событие происходит, сервис отправляет туда сообщение: например, платёж сменил статус.

Запрос через API вы начинаете сами: спрашиваете кассу, оплачен ли заказ. С вебхуком касса обращается к вашему сайту после изменения. ЮKassa описывает именно такой обмен в документации, проверенной 8 октября 2026.

ИИ-агенты могут написать приёмник и проверки вокруг него. После выпуска сообщения разбирает серверный код по заданным правилам. Поэтому при покупке разработки нужно согласовать, какой результат считается верным.

Адрес вебхука не удостоверяет отправителя. Знание адреса позволяет отправить туда запрос. До изменения заказа обработчик проверяет подлинность сообщения способом, который описан у выбранного сервиса.

Способы проверки различаются. GitHub описывает подпись сообщения с секретом, а ЮKassa предлагает проверить статус объекта через API или IP-адрес отправителя. Агенту нужны документы конкретного поставщика.

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

В задании нужно связать событие с вашим заказом. Товар, сумма и валюта сверяются с условиями этого заказа, включая согласованные скидки. Тестовая оплата остаётся в тестовом сценарии.

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

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

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

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

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

Проверка дошла дальше подписи. Кабинет кассы общий для продуктов, поэтому в обработчик добавили сверку товара. Уведомление об оплате другого товара перестало служить основанием для доступа к курсу.

Вторая находка касалась восстановления. Повтор узнавал уже созданный доступ и пропускал письмо, даже если отправка упала. Исправление отделило результат выдачи от результата отправки.

Смысл защиты от повторов здесь двойной: сохранить выданное и закончить недоставленное. Проверка «мы уже видели этот запрос» закрывает только первую половину. Полезный результат продажи включает письмо, с которым покупатель сможет войти.

Техническую ошибку разбирают вместе с ответственностью за ошибки агента. В случае вебхука приёмка касается всей цепочки до покупателя. Успех приёма сообщения не заменяет результат последнего шага.

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

Фраза «подключите вебхук» оставляет исполнителю слишком много решений. Запишите, какое событие принимаем, от какого сервиса и что должно измениться у покупателя. Хорошая задача для ИИ-агента заканчивается наблюдаемым результатом.

Агенту передают пример сообщения без данных реального покупателя. Для написания кода хватает тестовых заказов и описания проверки подписи. Обращение с данными клиентов у агентов стоит согласовать до начала работы.

Исполнитель пишет проверки на успешную доставку и на отказ. Чужой товар с подлинной подписью нужен в наборе примеров так же, как верная покупка. Иначе ошибка из нашей истории снова останется за пределами теста.

Человек принимает смысл этих проверок. Какие статусы дают право выдать товар, что делать после возврата и кто видит сбой, решает владелец процесса. Эти решения записывают в приёмку обработчика.

Подтверждение доставки и выполнение действия имеют разные статусы. ЮKassa принимает ответ HTTP 200 как подтверждение получения уведомления. Покупатель может ещё ждать письмо или доступ.

Долгую работу можно передать в очередь, как рекомендует GitHub. Тогда до ответа отправителю событие должно быть сохранено так, чтобы пережить остановку процесса. После ответа повтором и восстановлением управляет уже ваша система.

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

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

Если обработчик нужно заказать, передайте исполнителю таблицу проверок и пример заказа. На странице агентной разработки по подписке тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026. Обработчик входящего события можно обсудить как отдельную задачу с согласованными проверками и защитой от повторов.

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

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

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

1. Webhook сообщает о событии. До действия проверьте, что именно оно разрешает сделать.

2. Подлинность и содержание проверяют отдельно. Включите чужой товар в приёмку.

3. Повтор сохраняет выполненное и продолжает незавершённое. Проверьте одновременные доставки.

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

5. Заберите журнал результата и способ восстановить шаг. Ошибку превращайте в проверку до следующего выпуска.