Интеграция Тильды со СДЭК: расчёт доставки и передача заказов

Задача «прикрутить доставку СДЭК к Tilda» выглядит простой ровно до момента, когда встроенный виджет начинает считать доставку по одному-двум тарифам вместо полного списка, а заказ у клиента не долетает до личного кабинета СДЭК. Интеграцию тильда сдэк я делаю с 2021 года на проектах разного масштаба: от одностраничников с калькулятором доставки до магазинов с потоком 300+ заказов в месяц, где заявки уходят в СДЭК автоматически. В статье разберу рабочие способы подключения, покажу, где нативный виджет упирается в потолок, и дам код для передачи заказов через API без ручного дублирования данных менеджером.

Способы подключения СДЭК к Tilda

У Tilda есть три пути настроить доставку СДЭК, и они закрывают разные задачи.

Первый - встроенный блок «Доставка» в настройках интернет-магазина. Включается за 10-15 минут: вводишь код личного кабинета СДЭК, ключ и пароль от API, указываешь склад отправления. Виджет сам считает тарифы и сроки на странице оформления заказа. Подходит для простых магазинов с одним складом и стандартными габаритами товара.

Второй - встроенный виджет плюс готовый модуль ограничения доставки по зонам на карте. Тариф СДЭК по-прежнему считает штатный калькулятор, а модуль решает соседнюю задачу: сверяет адрес покупателя с полигонами на Яндекс.Карте, показывает условия для зоны (курьер, СДЭК или самовывоз) и не даёт оформить заказ по адресу вне покрытия.

Третий - кастомная интеграция через вебхук Tilda и собственный backend, который обращается к API СДЭК напрямую. Это единственный вариант, если заказы должны создаваться в личном кабинете СДЭК автоматически, если складов отправления несколько или если нужно считать доставку для нестандартных грузов вроде мебели.

Расчёт стоимости доставки СДЭК на сайте

Встроенный калькулятор Tilda дергает метод расчёта тарифа СДЭК (calculator/tariff), передавая код города отправителя, код или почтовый индекс получателя, вес и габариты позиций из корзины. На практике он часто отдаёт не весь список доступных тарифов, а два-три: обычно «Посылка склад-склад» и «Посылка склад-дверь», хотя в личном кабинете подключено больше вариантов. Проверяю это в первую очередь, когда клиент жалуется, что доставка «дорогая» или «не считается для его города».

Если магазин возит курьером только внутри своих районов, а остальным отдаёт СДЭК, я обычно ставлю поверх калькулятора готовый модуль ограничения доставки по зонам для Tilda: зоны рисуются полигонами в Яндекс.Конструкторе карт, скрипт сверяет с ними адрес в корзине, подставляет условия для зоны и блокирует оформление вне покрытия, а тариф СДЭК по-прежнему считает встроенный калькулятор.

Важная деталь по весу: СДЭК считает по большему из двух значений, фактическому и объёмному (габариты, делённые на коэффициент 5000 или 4000 в зависимости от тарифа). Если в Tilda товар заведён с весом «0.1 кг» для галочки, а по факту в коробке 2 кг с упаковкой, на пункте приёма пересчитают стоимость, и разница ляжет либо на магазин, либо всплывёт претензией от клиента.

Ограничения нативного виджета СДЭК в Tilda

Виджет закрывает базовый сценарий, но на объёме заказов упирается в конкретные вещи:

• не работает с несколькими складами отправления одновременно - только один код города-отправителя в настройках;
• не показывает доставку по индивидуальным договорным тарифам, если они не совпадают со стандартным списком СДЭК;
• карта ПВЗ иногда не прогружается в мобильном Safari при подключении через iframe без ускоренной загрузки;
• если API СДЭК не отвечает вовремя (бывает при плановых работах на их стороне), блок доставки на сайте просто пустой, а не показывает резервную цену.

Последний пункт штатно не лечится, и модуль зон на карте здесь не поможет: он проверяет адрес, а не считает тариф. Резервную цену при недоступном API даёт только кастомная интеграция со своим backend, где хранятся последние расчёты.

Автоматическая передача заказов в СДЭК через API

Схема рабочая и проверенная: Tilda отправляет вебхук на созданный заказ, сервер обменивает client_id и client_secret на токен доступа (он живёт час, expires_in 3600 секунд), затем создаёт заказ методом POST /v2/orders с данными получателя, тарифом и упаковками. В ответ СДЭК возвращает uuid заказа, а трек-номер приходит позже отдельным вебхуком, когда заказ фактически принят на склад.

const axios = require('axios');

app.post('/webhook/tilda-order', async function (req, res) {
  const tokenResponse = await axios.post('https://api.cdek.ru/v2/oauth/token', null, {
    params: {
      grant_type: 'client_credentials',
      client_id: process.env.CDEK_CLIENT_ID,
      client_secret: process.env.CDEK_CLIENT_SECRET
    }
  });
  const token = tokenResponse.data.access_token;

  const order = {
    tariff_code: 136,
    sender: { company: 'Магазин', name: 'Отправитель' },
    recipient: { name: req.body.name, phones: [{ number: req.body.phone }] },
    packages: [{ number: '1', weight: 500, length: 20, width: 15, height: 10 }]
  };

  await axios.post('https://api.cdek.ru/v2/orders', order, {
    headers: { Authorization: 'Bearer ' + token }
  });

  res.sendStatus(200);
});

Токен и секрет должны жить только на сервере. Хранить их в скрипте на странице Tilda небезопасно: исходный код доступен любому в браузере, и через такой ключ можно создавать заказы от имени магазина или менять данные в личном кабинете СДЭК.

Автоматизация заказов через n8n и Tilda-вебхуки

Если писать отдельный backend под задачу избыточно, связку собираю в n8n: узел Webhook принимает заказ от Tilda, Function-нода приводит поля к формату СДЭК, следом идут два HTTP Request (получение токена и создание заказа), и в конце уведомление в Telegram или запись в CRM. На простой сценарий с одним складом такая цепочка занимает день работы вместо нескольких дней на написание и отладку собственного сервиса.

Одна деталь, которая ломает такие схемы: токен СДЭК живёт час, и если n8n дергает создание заказа без обновления токена, через 60 минут после последнего запроса начинают сыпаться ошибки авторизации. Решается кэширующей нодой или проверкой времени жизни токена перед каждым запросом на создание заказа.

Типичные ошибки при интеграции Tilda и СДЭК

1. Код тарифа (tariff_code) в запросе не совпадает с тем, что реально подключено в личном кабинете СДЭК - заказ падает с ошибкой 400.
2. Вес товара в Tilda указан «для галочки», без учёта упаковки - стоимость доставки пересчитывается на складе и расходится с той, что видел клиент при оформлении.
3. Вебхук об изменении статуса заказа от СДЭК не обрабатывается - трек-номер клиенту не приходит, и менеджер узнаёт о готовности заказа вручную из личного кабинета.
4. Клиент и секрет СДЭК зашиты в клиентском Tilda-скрипте вместо серверной части - прямая уязвимость, обмен токена должен происходить только на бэкенде.
5. Интеграцию сразу выкатывают в продакшен, минуя тестовый контур СДЭК (test.api.cdek.ru), из-за чего первые реальные заказы становятся тестовыми на живых деньгах.

При комплексной интеграции - расчёт по API, автосоздание заказа, обработка статусов - закладываю на разработку и тестовый прогон 1-2 недели, в зависимости от числа складов и подключённых тарифов. Разовую доработку вроде фикса калькулятора под конкретный регион делаю быстрее, за несколько дней.

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

Сколько стоит интеграция Tilda и СДЭК под ключ?

Зависит от объёма: если нужен только расчёт доставки по API без автосоздания заказов, это ближе к доработке скрипта. Комплексная интеграция с передачей заказов, обработкой статусов и подключением CRM у меня стоит от 40 000 ₽, срок 1-2 недели.

Можно ли обойтись без программиста, используя только настройки Tilda?

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

Что делать, если виджет СДЭК не считает доставку для части городов?

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

Как передавать клиенту статусы заказа - доставлен, в пути, ожидает в ПВЗ?

СДЭК отправляет вебхуки на изменение статуса заказа на публичный URL, который нужно зарегистрировать в личном кабинете. Сервер принимает эти события и либо обновляет запись в CRM, либо шлёт уведомление клиенту через email или мессенджер - зависит от того, куда уже настроена отправка заказов из Tilda.