Webhooks Завершено 1 / 15
Как принять Многие сервисы отдают данные по простой схеме. Вы отправляете запрос, webhook сервис присылает ответ. Хотите узнать курс валюты? Спросили, получили Когда нужен число. Это удобно, когда момент обращения выбираете вы сами. промежуточный сервис Но часто бывает наоборот. Событие происходит на стороне сервиса, и вы Что может пойти не хотите узнать о нем сразу. Клиент оплатил заказ в ЮKassa. Пользователь так написал боту в Telegram. Кто-то заполнил форму на лендинге Tilda. Как просить Claude Постоянно опрашивать сервис «ну что, есть новости?» неэффективно и помочь медленно. Webhook-URL это тоже секрет В таких случаях работает обратная схема. Сервис сам стучится к вашему Самостоятельная приложению по заранее оговоренному адресу и приносит данные о работа событии. Этот адрес и называется webhook. Дополнительные материалы
Типовые сценарии идут по одному и тому же шаблону:
Прием оплаты. ЮKassa отправляет webhook на ваш сайт, когда платеж проходит. Сайт получает уведомление и открывает доступ к платному контенту. Бот в Telegram. Каждое сообщение пользователя бот получает как webhook. Telegram стучится по адресу, который вы зарегистрировали при создании бота. Заявка с лендинга в CRM. Tilda при заполнении формы отправляет webhook в amoCRM. В CRM появляется новая сделка, и менеджеру не нужно ничего копировать руками.
Запомнить про webhook нужно одно. Это HTTP-запрос, обычно POST с JSON внутри. Приходит он в момент самого события, ждать его по расписанию не нужно.
Как принять webhook Чтобы получать webhook, сервису нужен адрес, куда он отправит POST- запрос. Такой адрес часто называют webhook URL, endpoint или URL приемщика.
Например, CRM может выдать URL для приема заявок. Таблица может принять данные через специальный webhook. Чат может дать адрес, по которому можно отправить сообщение в канал. В таком случае вы берете URL из настроек одного сервиса и вставляете его в настройки другого.
Посмотрим на заявку с лендинга. В Tilda есть форма, а в amoCRM нужна новая сделка. Когда посетитель нажимает кнопку отправки, Tilda собирает поля формы и отправляет POST-запрос на адрес приемщика. Приемщик читает JSON и создает сделку в amoCRM.
Посетитель отправил форму -> Tilda собрала поля -> Tilda отправила webhook -> приемщик получил JSON -> в CRM появилась заявка
Внутри webhook может выглядеть так:
{
"name": "Анна",
"phone": "+79990000000",
"source": "tilda",
"form_id": "consultation",
"submitted_at": "2026-06-13T14:25:00+03:00","comment": "Хочу обсудить запуск лендинга" }
Это обычный JSON. По именам полей видно, кто оставил заявку, какой телефон указал, откуда пришло событие и когда оно произошло. Приемник должен понять эти поля. Если CRM ждет поле contact_phone , а Tilda присылает phone , данные придется сопоставить в настройках или через промежуточный сервис.
Практически настройка проходит в четыре шага. Сначала находят webhook URL у приемника. Потом вставляют этот URL в сервис, который отправляет событие. После этого отправляют тестовую заявку. В конце открывают журнал доставки и смотрят, дошел ли запрос.
Журнал доставки важнее, чем кажется. В нем видно время отправки, адрес, статус ответа и иногда тело ошибки. Если приемник ответил 200 OK , он принял webhook. Если вернулся 401 , проблема в авторизации. Если 404 , скорее всего указан неправильный URL. Если 500 , приемник упал во время обработки.
Когда нужен промежуточный сервис Напрямую сервисы соединяются редко. Формат данных от отправителя может оказаться непонятным для приемника. Может не хватать авторизации, нужного поля или проверки. Иногда отправитель умеет отправлять webhook, хотя приемник вообще не умеет принимать входящие запросы.
Тогда между ними ставят сервис автоматизации вроде n8n, Albato, Make или Zapier. Он принимает webhook, показывает входящий JSON, дает переименовать поля, проверить условия и отправить результат дальше. В сценарии с лендингом такой сервис может принять заявку, привести
телефон к одному формату, отбросить пустые заявки и только потом создать сделку в CRM.
Что может пойти не так В webhook чаще всего ломаются мелкие настройки.
Неправильный адрес. В настройках легко скопировать тестовый URL вместо рабочего или потерять часть длинного адреса. В журнале доставки это обычно видно по статусу 404 или сообщению «not found».
Сервис ждет другие поля. Отправитель прислал phone , а приемник ищет tel или contact_phone . Запрос дошел, но карточка в CRM создалась без телефона. Тут помогает просмотр входящего JSON и сопоставление полей.
Не прошла авторизация. Некоторые приемники требуют токен, подпись запроса или секрет в URL. Если токена нет или он устарел, приемник вернет 401 или 403 .
Webhook пришел дважды. Сервисы иногда повторяют отправку, если не уверены, что событие принято. Поэтому обработчик должен спокойно переживать повтор. Например, по номеру оплаты или идентификатору заявки он проверяет, не создавалась ли такая запись раньше.
Приемник ответил слишком поздно. Некоторые сервисы ждут ответ только несколько секунд. Если обработка долгая, webhook считают неуспешным и отправляют повтор. Для сложных сценариев приемник сначала быстро отвечает, а тяжелую работу выполняет отдельно.
Как просить Claude помочь
Claude полезен, когда нужно понять входящий JSON, сопоставить поля или найти причину ошибки. Для этого ему нужны конкретные данные, а не общее описание «webhook не работает».
Хороший запрос выглядит так:
Вот JSON, который приходит из Tilda. Вот поля, которые ждет amoCRM. Сопоставь поля и скажи, каких данных не хватает.
Или так:
Webhook вернулся со статусом 401. Вот настройки авторизации из документац и заголовки запроса. Найди, что настроено неправильно.
Еще можно попросить агента написать маленький приемник webhook для проекта. Тогда в задаче стоит указать, какой путь должен принимать запрос, какие поля обязательны, что считать дублем и куда записывать данные. Чем точнее описано событие, тем меньше агенту придется угадывать.
Webhook-URL это тоже секрет Адрес, по которому вы принимаете webhook, стоит беречь так же, как ключ. Если он утек, на него могут слать левые данные и забивать вашу таблицу мусором или подделывать заявки.
У n8n, Albato, Salebot и похожих сервисов есть подпись запросов, токен в URL или отдельная проверка источника. Включайте такую защиту, когда она доступна. Тестовый URL и рабочий URL храните отдельно, чтобы случайная проверка не создала настоящую сделку или оплату.
Не публикуйте webhook URL в открытом виде, не вставляйте его в скриншоты и не пересылайте в общий чат. Если адрес утек, выпустите новый URL или смените токен в настройках приемщика.
Самостоятельная работа В этом задании вы соедините форму на Tilda с amoCRM. Посетитель отправляет форму, а в CRM появляется новая заявка. В интерфейсе вы настраиваете готовую интеграцию, а внутри работает webhook- подход: событие из одного сервиса сразу уходит в другой.
Форма на Tilda
Создайте в Tilda новую страницу Заявка на консультацию . Добавьте блок с формой и настройте четыре поля:
Name Phone Service Comment
Подписи для посетителя сделайте русскими: имя, телефон, услуга, комментарий. Кнопку назовите Отправить заявку .
Опубликуйте страницу на бесплатном адресе Tilda.
Подключение amoCRM
Откройте настройки сайта в Tilda. В разделе форм подключите приемщик данных amoCRM. В окне доступа укажите аккаунт amoCRM и разрешите Tilda передавать заявки.
В настройках приемщика укажите воронку и ответственного пользователя. Тему заявки задайте так:
Заявка с Tilda: {{Name}}
Вернитесь на страницу с формой. В настройках блока формы включите отправку данных в amoCRM и заново опубликуйте страницу.
Тестовая заявка
Откройте опубликованную страницу и отправьте заявку:
Name: Анна Phone: +79990000000 Service: консультация Comment: Хочу обсудить запуск лендинга
Подождите несколько минут и откройте раздел с лидами или сделками в amoCRM.
Проверка: в amoCRM появилась новая заявка из Tilda. В карточке видны имя Анна, телефон, услуга, комментарий и источник заявки. Если заявки нет, откройте в Tilda журнал ошибок формы и проверьте, что у блока формы включен приемщик amoCRM.
Дополнительные материалы Что такое API простыми словами