5Post и Тильда: интеграция пунктов выдачи для сайта

Интеграция 5Post и Тильды - задача, с которой ко мне регулярно приходят владельцы интернет-магазинов на Tilda: у конструктора есть готовый блок доставки СДЭК, а под сеть постаматов и пунктов выдачи 5Post (принадлежит X5 Group - Пятёрочка, Перекрёсток, Чижик) ничего из коробки нет. Разбирался с этой связкой на нескольких проектах, ниже - рабочая схема, а не теория из документации.

Почему у 5Post нет готового блока в Тильде

Tilda встраивает в форму заказа виджет выбора точки только для ограниченного списка партнёров, и СДЭК туда попал, а 5Post нет. Формально это означает, что карта постаматов и ПВЗ 5Post на странице заказа сама не появится, сколько бы настроек в панели Tilda ни перебирать.

На практике клиенты сначала пробуют обойтись стандартной формой с текстовым полем «адрес доставки», а через пару недель понимают, что покупатели путают адреса, менеджер вручную сверяет ближайший ПВЗ по каждому заказу, и часть посылок уходит не туда. После этого обращаются за кастомным скриптом, который добавляет полноценный выбор точки выдачи прямо в форму.

Архитектура интеграции 5Post и Tilda

Прямой запрос с фронтенда Tilda к API 5Post не сделать: там нужен токен авторизации, который нельзя светить в браузерном JS, плюс сами эндпоинты 5Post не отдают заголовки CORS для чужих доменов. Поэтому между Zero Block и 5Post всегда стоит прослойка.

Схема, которую использую чаще всего:

• Backend-прокси (обычно Node.js или PHP на VPS в РФ) хранит токен 5Post и проксирует запросы на получение точек выдачи, расчёт стоимости и создание отправлений.
• Скрипт в Zero Block дергает не сам 5Post, а свой прокси, получает список точек и рисует виджет на странице.
• При отправке формы заказа Tilda уходит вебхук на прокси, оттуда данные летят в 5Post (создание отправления) и параллельно в CRM.

Для магазинов с потоком до сотни заказов в день писать отдельный бэкенд не всегда оправданно - вместо него ставлю n8n: вебхук из Tilda принимает узел Webhook, следующий узел HTTP Request дергает API 5Post, третий пишет сделку в amoCRM или Bitrix24. Разворачивается такая цепочка за пару дней и не требует поддержки отдельного сервера под каждый проект.

Виджет выбора пункта выдачи: карта или список

Есть два подхода к отображению точек 5Post на странице заказа. Карта с метками через Yandex Maps API выглядит привычнее для покупателя, но на мобильной версии Tilda часто тормозит и плохо ужимается в узкий блок формы - на адаптиве обычно переключаю карту на список точек с фильтром по городу и району, он и грузится быстрее, и не требует дополнительного API карт.

Точки выдачи 5Post по городу получаю через свой прокси и кэширую на сутки: список ПВЗ и постаматов меняется не каждый день, а дёргать API 5Post при каждом визите на страницу заказа - лишняя нагрузка и риск словить задержку ответа в пиковые часы.

ID выбранной точки записываю в скрытое поле формы:

<input type="hidden" name="pvz_id" id="pvz-selected-id" value="">

Это поле уходит вместе с остальными данными в вебхук Tilda при отправке заказа, и дальше его читает уже прокси или n8n. Если магазин часть заказов возит своим курьером, в библиотеке есть готовый скрипт ограничения доставки по зонам на карте для Tilda, который закрывает соседнюю задачу - показать покупателю зону и цену доставки по адресу и не дать оформить заказ вне покрытия.

Расчёт стоимости и сроков доставки через API

5Post отдаёт тариф по параметрам отправления: город получателя, вес, габариты посылки. Здесь два рабочих варианта.

Динамический расчёт дергает API 5Post при каждом изменении корзины или выборе точки - показывает точную цену и срок, но добавляет лишний запрос и небольшую задержку на странице заказа. Зашитая тарифная сетка по городам и весовым категориям грузится мгновенно, но её нужно вручную сверять с тарифами 5Post раз в месяц-два, когда служба меняет цены.

Для магазинов с однотипным товаром - одежда, аксессуары, мелкая электроника - сетка обычно устраивает: вес почти не гуляет, ошибка в расчёте копеечная. Для мебели, техники или товаров с сильным разбросом веса без живого расчёта через API не обойтись, иначе на упаковках свыше нескольких килограммов магазин либо переплачивает за доставку, либо недобирает с покупателя.

Срок доставки 5Post отдаёт вместе с тарифом в том же ответе API - вывожу его рядом с ценой в виджете, чтобы покупатель видел не только «сколько платить», но и «сколько ждать», это заметно снижает число вопросов в поддержку после оформления заказа.

Передача заказа в 5Post и синхронизация с CRM

После оплаты - чаще всего это встроенный в Tilda эквайринг Т‑Банка - данные заказа и ID выбранной точки уходят на прокси. Он создаёт отправление в 5Post, получает номер отправления и трек-номер, и кладёт их в сделку CRM вместе с данными покупателя.

Здесь важна обработка сбоев: если API 5Post не отвечает 20-30 секунд, заказ не должен потеряться. Сначала фиксирую заказ в очереди (таблица на своём сервере или узел в n8n), затем пытаюсь создать отправление в 5Post, при ошибке - повторяю попытку через несколько минут вместо того, чтобы просто вернуть покупателю ошибку оформления.

Данные покупателей - телефон, адрес, выбранная точка выдачи - храню на серверах в РФ, а не в Google Sheets или Airtable: для интеграций с персональными данными это не формальность, а требование 152-ФЗ о локализации.

Статусы доставки обратно в форму Tilda не завожу - конструктор их просто не принимает. Вместо этого настраиваю уведомление менеджеру в Telegram при смене статуса заказа в 5Post (готов к выдаче, вручён), если клиенту важно отслеживать доставку без захода в личный кабинет 5Post.

5Post, СДЭК и Boxberry в Тильде: что выбрать

Сравнение трёх служб, с которыми чаще всего работаю на проектах Tilda:

Стоимость доставки для конечного покупателя формируется тарифами самой службы и зависит от города и веса посылки, а не от того, на каком конструкторе сделан сайт - сравнивать «тарифы Tilda» и «тарифы не Tilda» бессмысленно. Разница между службами в контексте Tilda ровно одна: у СДЭК виджет уже есть в конструкторе, у 5Post и Boxberry его нужно делать отдельно.

Из-за плотности сети постаматов 5Post нередко выигрывает у СДЭК именно в крупных городах и городах-миллионниках - там точки 5Post стоят почти в каждом квартале за счёт сети Пятёрочки, и покупателю не приходится ехать через весь город за посылкой.

Частые ошибки при интеграции 5Post и Tilda

За несколько проектов на этой связке набрался стабильный список граблей:

• Скрипт в Zero Block упирается в ограничение по размеру кода - сложную логику виджета выношу в отдельный внешний JS-файл, подключаемый через <script src>, а не пишу весь код прямо в блоке.
• Попытка дёрнуть API 5Post напрямую с фронта заканчивается ошибкой CORS - без прокси-сервера это не работает в принципе.
• Виджет тестируют только на десктопе, а на мобильной версии карта не помещается в блок или не прокручивается - адаптив под мобильную Tilda делаю отдельно, обычно списком вместо карты.
• Нет ретраев при создании отправления - если 5Post на секунду недоступен, заказ пропадает вместо того, чтобы уйти в отправление через повторную попытку.
• Постаматы и ПВЗ 5Post обрабатываются в скрипте одинаково, хотя у них разная логика хранения и получения посылки - если это не разделить в интерфейсе, покупатель может выбрать постамат для крупногабаритного товара, который туда физически не влезет.

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

Сколько стоит интеграция 5Post с Tilda?

Точечная доработка вроде смены отображения виджета или добавления фильтра по городу стоит от 3 000 ₽. Комплексная интеграция с бэкенд-прокси, расчётом стоимости через API и синхронизацией с CRM - от 40 000 ₽, итоговая цена зависит от того, нужен ли динамический расчёт тарифов или хватит тарифной сетки.

Можно ли подключить 5Post без своего сервера?

Без прокси-сервера или аналогичного сервиса не обойтись, потому что напрямую с фронта Tilda к API 5Post не достучаться из-за CORS и требований к хранению токена. Легковесная альтернатива серверу - workflow в n8n: вебхук из Tilda, запрос к API 5Post и запись в CRM собираются без написания отдельного бэкенда, автоматизация в n8n у меня стоит от 25 000 ₽.

Работает ли виджет выбора ПВЗ на мобильной версии сайта?

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

Как быстро делается такая интеграция?

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