Интеграция скрипта Тильда с внешним API - тема, с которой ко мне чаще всего приходят через полгода-год после запуска сайта: заявки скапливаются на почте, менеджер вручную переносит их в CRM, доставку считают по прайсу из головы, а оплату присылают ссылкой в мессенджере. Разберу на реальном кейсе, как выглядит связка Tilda + вебхук + серверный обработчик - от формы на сайте до записи заказа в CRM, расчёта доставки через СДЭК и приёма оплаты через эквайринг Т‑Банка.
Зачем встраивать скрипт в Tilda, если есть готовые блоки CRM
Tilda сама умеет отправлять лиды в amoCRM, Bitrix24 и RetailCRM через встроенные интеграции в панели сайта. Для типового лендинга с одной формой этого достаточно. Но встроенная интеграция работает по жёсткому сценарию: одна форма - одна CRM, без промежуточной логики между ними. Как только нужно посчитать стоимость доставки до отправки формы, проверить остаток товара на складе, выставить платёж на точную сумму с учётом скидки или разослать разные уведомления в зависимости от региона клиента - стандартных настроек не хватает. Здесь между формой и целевым сервисом встаёт кастомный скрипт.
На практике встречаю три типовых повода для такой доработки:
- форма отправляет данные в CRM, но менеджер всё равно вручную считает доставку и пишет клиенту цену отдельно;
- оплата принимается по статической ссылке, из-за чего сумма не привязана к конкретному заказу и легко ошибиться;
- заявки теряются, потому что уведомление уходит только на почту, а почту проверяют раз в день.
Из чего состоит связка: форма Tilda, вебхук и серверный обработчик
В настройках формы на Tilda есть поле «Вебхук» - туда добавляется URL, и при отправке формы Tilda POST-запросом шлёт на него все поля формы. Дальше нужен свой обработчик: небольшой сервис на Python или Node.js, который принимает запрос, обращается к внешним API и возвращает ответ клиенту - например, ссылку на оплату.
Ключи от СДЭК, Т‑Банка и CRM в JS-коде на стороне Tilda никогда не хранятся - скрипт в Zero Block виден любому в исходном коде страницы, а публикация ключа эквайринга в открытом доступе - это прямой путь к списанию чужих денег с вашего счёта или подмене суммы платежа. Все обращения к платным API идут только с сервера, скрипт на Tilda лишь передаёт данные формы на ваш эндпоинт и получает обратно готовый результат - например, стоимость доставки или ссылку на оплату.
Если сценарий типовой - форма плюс уведомление в Telegram без сложной логики - быстрее посмотреть библиотеку готовых скриптов для Tilda и адаптировать под свою задачу, чем писать обработчик с нуля.
Кейс: заявка на сайте → расчёт доставки СДЭК → оплата через Т‑Банк
Задача из практики: интернет-магазин на Tilda, форма заказа с полями «город», «товар», «вес», нужно на лету посчитать доставку СДЭК, создать платёж в Т‑Банке на сумму товар + доставка и уведомить менеджера в Telegram, чтобы заказ не потерялся между отправкой формы и обработкой в CRM.
Шаг 1: приём вебхука с формы
Tilda отправляет form-data на эндпоинт бэкенда. Проверяю обязательные поля, отбрасываю запросы без email - так меньше мусора от ботов и тестовых отправок.
Шаг 2: расчёт доставки СДЭК до создания платежа
Запрос к API СДЭК с городом и весом отправки, из ответа беру расчётную стоимость и срок. Если СДЭК не отвечает за 3-5 секунд - не блокирую заявку, а подставляю среднюю стоимость по региону и помечаю заказ на ручной пересчёт менеджером.
Шаг 3: платёж в Т‑Банке на точную сумму
Создаю платёж через API эквайринга Т‑Банка на сумму «товар + доставка», привязывая к нему номер заказа как идентификатор - это важно для сверки, если клиент оплатит с задержкой или платёж уйдёт в статус ошибки и его нужно будет пересоздать без задвоения заказа.
from flask import Flask, request, jsonify
app = Flask(__name__)
@app.route("/webhook/tilda", methods=["POST"])
def tilda_webhook():
data = request.form.to_dict()
delivery = calc_cdek_price(data["city"], data["weight"])
order_id = save_order(data, delivery)
payment = create_tbank_payment(
order_id=order_id,
amount=int(data["price"]) + delivery["price"],
email=data["email"],
)
notify_telegram(order_id, data, delivery)
return jsonify({"payment_url": payment["url"]})
Шаг 4: уведомление в Telegram и запись в CRM
Параллельно с созданием платежа отправляю сообщение в рабочий чат через бота на aiogram - менеджер видит заказ раньше, чем клиент успевает закрыть вкладку с оплатой. Запись в CRM делаю отдельным вызовом уже после подтверждения оплаты, по вебхуку от Т‑Банка, а не сразу при отправке формы - иначе в базе копятся неоплаченные «заказы-призраки» от тех, кто просто передумал на этапе оплаты.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Частые ошибки при внедрении скрипта на Tilda
За несколько лет таких доработок вижу одни и те же грабли:
- Ключи API прямо в коде Zero Block. Исходный код страницы открыт всем, ключ эквайринга или токен CRM утекает мгновенно.
- Нет обработки таймаутов. Если СДЭК или CRM отвечают дольше обычного, форма зависает на «Отправка…» и клиент уходит с сайта.
- Тестирование только на десктопе. На мобильной вёрстке Tilda часть полей формы может отправляться с другими именами - если бэкенд их не ждёт, заказ теряется молча.
- Нет идемпотентности. Двойной клик по кнопке отправки формы создаёт два платежа на одну и ту же сумму вместо одного.
- Контакты клиентов складывают в зарубежные облачные таблицы. Для персональных данных нужен сервер в России - это требование 152-ФЗ, а не вопрос удобства.
Сколько стоит и сколько занимает интеграция скрипта Тильда с API
Цена зависит от количества внешних сервисов в цепочке и от того, есть ли уже готовый бэкенд под задачу или его нужно поднимать с нуля.
| Тип работы | Что входит | Срок | Цена |
|---|---|---|---|
| Простая доработка скрипта | одна форма, один вебхук, без внешних платных API | 1-2 дня | от 3 000 ₽ |
| Комплексная интеграция | CRM + эквайринг + СДЭК + уведомления, свой бэкенд | 1-3 недели | от 40 000 ₽ |
| Автоматизация в n8n вместо кастомного бэкенда | та же логика без написания серверного кода | 3-7 дней | от 25 000 ₽ |
n8n подходит, когда сценарий укладывается в цепочку «вебхук → HTTP-запрос → условие → следующий сервис» без сложных расчётов внутри. Как только появляется своя бизнес-логика вроде пересчёта скидок или проверки остатков на складе перед оплатой, дешевле и надёжнее написать отдельный сервис, чем городить это внутри визуального конструктора сценариев.
На рынке цена похожей интеграции у студий и фрилансеров обычно колеблется в диапазоне 30 000-80 000 ₽ за комплексный сценарий - разброс сильно зависит от того, включена ли туда доработка самого бэкенда СДЭК или Т‑Банка на стороне клиента, или подрядчик подключается к уже готовому API.
Как проверить и поддерживать интеграцию после запуска
После запуска смотрю логи первых 20-30 реальных заявок вручную - автоматические тесты не покажут, что клиент из Казахстана ввёл город, которого нет в справочнике СДЭК, или что мобильный Safari обрезал часть данных формы при автозаполнении.
Отдельно проверяю сценарии сбоя: что происходит, если СДЭК недоступен, если Т‑Банк вернул ошибку по карте, если Tilda задвоила отправку формы из-за медленного интернета у клиента. Каждый из этих случаев должен приводить к понятному сообщению для клиента и уведомлению для менеджера, а не к молчаливой потере заказа.
Tilda время от времени меняет вёрстку и поведение блоков форм, и скрипт, который работал полгода, может перестать ловить нужное событие после обновления платформы. Разовая доработка не подразумевает слежения за такими изменениями - для этого беру отдельную техподдержку от 15 000 ₽/мес, если клиенту нужно, чтобы интеграцию проверяли и чинили на регулярной основе, а не постфактум, когда заказы уже перестали доходить.
Когда стандартных блоков не хватает
Кастомный скрипт
от 3 000 ₽
Подробнее →Частые вопросы
Можно ли подключить к Tilda любой внешний API без переезда на другую платформу?
Большинство API, у которых есть HTTP-эндпоинты и документация - СДЭК, Т‑Банк, amoCRM, Bitrix24, произвольные CRM и учётные системы - подключаются к Tilda через связку «вебхук формы плюс свой серверный обработчик». Переезд на WordPress или отдельный веб-сервис имеет смысл, только если нужен личный кабинет пользователя или сложная логика внутри самого сайта, а не в интеграции с внешним сервисом.
Где хранить ключи API при интеграции с Tilda?
Только на сервере обработчика, никогда в коде Zero Block или в самой Tilda - исходный код страницы доступен любому посетителю сайта. Ключи держу в переменных окружения сервера, а не в файле проекта, который может случайно попасть в открытый репозиторий.
Что делать, если Tilda обновит вёрстку и скрипт перестанет работать?
Такое случается: платформа меняет разметку блоков или поведение форм, и скрипт, завязанный на конкретные классы или имена полей, ломается тихо - заявки перестают доходить, но форма внешне работает как обычно. Отслеживать такие изменения нужно отдельно от разовой разработки - для этого есть техподдержка на регулярной основе, а не разовая доработка «навсегда».
Нужен ли отдельный сервер для приёма вебхуков от Tilda, или хватит бесплатного хостинга?
Для продакшена нужен сервер с постоянным доступом и стабильным аптаймом - бесплатные хостинги для скриптов часто «засыпают» при отсутствии запросов, и первый вебхук после паузы теряется или обрабатывается с задержкой в десятки секунд, за которые клиент уже закрыл вкладку с оплатой. Для интеграции с реальными платежами и доставкой это неприемлемо, поэтому обработчик размещаю на обычном VPS или в облаке с гарантированной доступностью.