Заявка с сайта на Тильде обычно уходит на почту или в подключённую CRM через готовый модуль формы. Но если нужно завести лид в собственную базу, дёрнуть внутренний API или сразу поставить сделку в очередь на обработку, самый гибкий инструмент - вебхуки Тильды. Форма отправляет POST-запрос с данными на указанный вами URL в момент отправки, без задержек на почтовые очереди и без ограничений встроенных сервисов. На практике я подключаю этот способ там, где заявка должна сразу попасть в свою систему, а не только в письмо менеджеру.
По теме статьи
Готовое решение
Подсказки адреса DaData в форме Tilda
Посетитель начинает вводить адрес, и под полем появляются готовые варианты из базы DaData. Выбранная строка встаёт в поле целиком. Без jQuery, на бесплатном тарифе DaData.
Бесплатно
Кастомный скрипт
Когда стандартных блоков не хватает
Доработка сайтов на Тильде: скрипты для корзины, промокоды, зоны доставки, интеграции с CRM и Telegram. Простой скрипт от 3 000
от3 000 ₽
Чем вебхук отличается от email-уведомления и CRM-интеграции
У формы в Тильде можно включить сразу несколько каналов одновременно: письмо себе на почту, отправку в подключённую CRM и вебхук на свой сервер - они не мешают друг другу и работают параллельно. Разница в том, что происходит с данными дальше.
| Способ получения заявки | Что происходит | Нужен ли свой сервер |
|---|---|---|
| Email-уведомление | Тильда отправляет письмо с данными формы на указанный адрес | Нет |
| Готовая CRM-интеграция | Заявка создаётся в подключённой CRM через встроенный модуль формы | Нет |
| Вебхук | Тильда отправляет POST-запрос с полями формы на ваш URL, дальше данные обрабатывает ваш код | Да, нужен endpoint, который примет запрос |
Email и готовая CRM-интеграция закрывают большинство типовых сценариев. Вебхук нужен, когда заявку требуется обработать программно: записать в свою базу, дёрнуть внутренний сервис, поставить задачу в очередь или сразу отфильтровать спам по каким-то условиям до того, как заявка попадёт к менеджеру.
Как подключить вебхук в настройках формы Тильды
Подключение делается прямо в редакторе, без правки кода страницы.
- Открываете «Настройки сайта», раздел «Формы», приёмщик «Webhook»: «Чтобы активировать вебхук, откройте Настройки сайта → Формы → Webhook». Адрес обработчика задаётся один раз на весь сайт, а не в отдельном блоке.
- Указываете адрес своего скрипта - обязательно с HTTPS: «Также скрипт должен использовать защищенный протокол HTTPS». Если нужно передавать куки, ставите галочку и сохраняете.
- Сразу после сохранения Тильда проверяет адрес сама: «Сразу после подключения Webhook будет отправлен запрос с данными test=test (метод POST) и ожидается, что Webhook вернет код 200 OK».
- Открываете страницу в редакторе, кликаете на блок с формой и в меню «Контент» отмечаете сервис приёма данных Webhook.
- Сохраняете и публикуете страницу: без публикации новый вебхук не заработает, даже если блок сохранён.
Сама настройка в Тильде занимает минут 10, основное время потом уходит на то, чтобы поднять и протестировать сервер, который эти данные примет. Если сервер ещё не готов и вы тестируете локально, подойдёт временный публичный туннель вроде ngrok - он выдаёт HTTPS-адрес, который перенаправляет запросы на localhost, и его можно временно вставить в поле вебхука для проверки.
Какие данные приходят в вебхуке от Тильды
Тильда отправляет POST-запрос обычными полями формы, а не JSON: «Данные будут отправляться методом POST», «Чтобы получить все поля и значения без изменений нужно обратиться к переменной $_POST. $_POST это ассоциативный массив данных». Ключи в теле - это имена полей формы, которые вы задали при её создании (Name, Phone, Email, Comment и подобные), плюс два служебных: «Кроме полей из заявки приходят такие поля: tranid=467251%3A8442970 formid=form48844953, где tranid соответствует Lead id (уникальный номер заявки) из раздела «Заявки», а formid соответствует Block id (номер блока, с которого была отправка)». Часть символов приходит экранированной, «вместо @ (собаки) будет %40, вместо: (двоеточия) будет %3a», и разворачивает их urldecode. Точный набор служебных полей может немного отличаться в зависимости от типа блока, поэтому первое, что я делаю на новом проекте, это логирую сырое тело первого пришедшего запроса и смотрю на реальную структуру, а не полагаюсь на память или чужие примеры.
const rawBody = "Name=test+name&Phone=0123456789&Email=test%40email.com&tranid=467251%3A8442970&formid=form48844953";
const lead = Object.fromEntries(new URLSearchParams(rawBody));Если в форме есть кастомные поля - скрытые input с UTM-метками, выбор тарифа, чекбоксы согласия - они тоже попадут в тело запроса под теми именами, которые вы указали в настройках поля.
Как принять и обработать вебхук на своём сервере
Endpoint должен принимать POST, разбирать form-urlencoded и как можно быстрее отвечать 200: «Ссылка на скрипт должна быть доступна и скрипт должен отвечать в течение пяти секунд. В противном случае данные не отправятся, а система сделает еще две попытки их отправить, каждую через минуту». Тяжёлую логику (запись в базу, отправку писем, обращение к внешним API) лучше выносить после ответа или в отдельную очередь.
const express = require('express');
const app = express();
app.use(express.urlencoded({ extended: true }));
app.post('/webhooks/tilda', (req, res) => {
const lead = req.body;
res.sendStatus(200);
console.log('Новая заявка:', lead.Name, lead.Phone);
// здесь сохраняем в свою БД, шлём в Telegram, ставим в очередь и т.д.
});
app.listen(3000, () => console.log('Webhook endpoint запущен на порту 3000'));Для идентификации запросов у приёмщика Webhook есть штатная настройка ключа: «При передаче данных через Webhook может понадобиться идентифицировать пользователей с помощью ключа API. В настройках приемщика можно указать имя ключа и его значение, а также указать метод передачи (POST или передача в заголовках)». Я задаю там свой ключ и проверяю его в коде до обработки тела запроса, а неочевидный путь вроде /webhooks/tilda/a3f9c1 оставляю как дополнительную меру.
Если в заявке есть телефон, почта или другие персональные данные клиента, храните их на сервере в России, а не в иностранных таблицах или облачных сервисах - это требование 152-ФЗ по локализации персональных данных, и я на проектах с вебхуками всегда завожу под это отдельную БД, а не полагаюсь на внешний сервис как единственное хранилище.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Уведомления о заявках в Telegram через вебхук
У Тильды есть встроенная интеграция с Telegram прямо в настройках формы - она отправляет шаблонное сообщение в привязанный бот или чат при каждой заявке. Для многих проектов этого достаточно. Но если нужно разное форматирование для разных форм, кнопки под сообщением, маршрутизация по отделам в зависимости от выбранного клиентом тарифа или отправка не только текста, но и файла с расчётом - тут удобнее принимать вебхук на своём сервере и пересылать данные через отдельного бота на aiogram, где формат сообщения и логика полностью в ваших руках.
Вебхуки Тильды в связке с n8n
Если не хочется поднимать и поддерживать собственный сервер ради одного endpoint, вебхук можно завести прямо на n8n. Нода Webhook в n8n сама выдаёт публичный HTTPS-адрес, его вставляете в настройки формы Тильды - и дальше строите цепочку из блоков: разбор полей, условия по содержимому заявки, отправку в Telegram, создание задачи в CRM, любые дополнительные проверки. Для проектов с несколькими формами и разной логикой обработки я обычно рекомендую именно настройку автоматизации в n8n - это быстрее, чем писать и деплоить отдельный сервис под каждый сценарий.
Если задача сложнее одной пересылки - например, вебхук должен запускать расчёт доставки, проверку промокода или синхронизацию с эквайрингом - это уже комплексная интеграция, а не разовая доработка. У меня такие проекты стартуют от 40 000 ₽. Простая доработка вроде проверки поля формы или преобразования данных перед отправкой в вебхук обычно стоит от 3 000 ₽.
Почему вебхук не приходит: типичные причины
Большинство проблем с вебхуками Тильды сводится к нескольким повторяющимся причинам.
- Страница сохранена, но не опубликована заново после изменения настроек вебхука.
- URL ведёт на localhost или недоступен из интернета - Тильда не сможет достучаться до вашего сервера.
- Адрес указан без HTTPS.
- Сервер отвечает с задержкой или падает с ошибкой до того, как успел отправить статус 200.
- Код на сервере ждёт поля с именем, которого в реальном запросе нет - названия полей берутся из настроек формы, а не придумываются заранее.
При отладке я сначала подставляю в поле вебхука адрес сервиса вроде webhook.site - он показывает сырые запросы без единой строчки кода на вашей стороне, и по нему сразу видно, доходят ли вообще запросы от Тильды и что именно в них лежит. Только после этого переключаю URL на реальный endpoint.
Условия и возможности Тильды меняются, поэтому перед запуском я уточняю их у самого сервиса.
Частые вопросы
Чем вебхук отличается от email-уведомления в Тильде?
Email-уведомление просто отправляет письмо с данными формы на почту. Вебхук отправляет те же данные POST-запросом на ваш сервер обычными полями формы, которые на PHP читаются из $_POST, и дальше их можно обрабатывать программно: сохранять в базу, пересылать в другие сервисы, запускать по ним любую логику. Оба канала можно включить одновременно в одной форме.
Можно ли включить вебхук и CRM-интеграцию одновременно?
Да, в настройках формы можно активировать сразу несколько сервисов - например, встроенную интеграцию с CRM для менеджеров и вебхук на свой сервер для внутренней автоматизации. Они работают параллельно и не конфликтуют друг с другом.
Как протестировать вебхук без своего сервера?
Проще всего вставить в поле вебхука адрес сервиса вроде webhook.site или ноду Webhook в n8n - оба сразу показывают, что реально приходит от Тильды, без необходимости разворачивать и деплоить код. После проверки структуры данных URL меняется на боевой endpoint.
Что делать, если Тильда отправляет заявки, а сервер их теряет?
Проверьте логи сервера на момент отправки тестовой заявки и убедитесь, что endpoint отвечает статусом 200 быстро, а не после долгой обработки. Если запросов действительно много и часть теряется из-за перегрузки, помогает класть входящие заявки в очередь сразу при получении и обрабатывать их отдельным процессом, а не внутри самого обработчика вебхука.