Интеграция с Яндекс Доставкой: подключение к магазину

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

Как работает API Яндекс Доставки: заявки и тарифы

В основе лежит две сущности. Первая - расчёт стоимости и сроков (оффер): магазин передаёт точки забора и выдачи, вес и габариты груза, а в ответ получает несколько тарифов с ценой и временем подачи. Вторая - заявка (claim): на основе выбранного оффера создаётся реальный заказ на курьера, у него появляется статус, номер и трек для отслеживания.

Из тарифов на практике чаще всего использую три: экспресс-доставку день в день по крупным городам, экономный тариф с доставкой на следующий день и курьерскую доставку из своей точки самовывоза. У каждого тарифа отдельная логика подачи заявки: экспресс требует более точного времени готовности заказа, экономный тариф спокойнее относится к окну сборки. Это стоит закладывать в бизнес-логику магазина ещё на этапе проектирования корзины, а не патчить потом.

Статусы заявки приходят через вебхук на URL, который вы указываете в личном кабинете отправителя: заявка принята, курьер найден, забор груза выполнен, доставлено. Без вебхука приходится опрашивать API по расписанию, что для интернет-магазина с десятками заказов в день превращается в лишнюю нагрузку и задержку в статусах на несколько минут.

Получение токена и настройка личного кабинета отправителя

Подключение начинается в личном кабинете партнёра Яндекс Доставки, где регистрируется юрлицо или ИП и создаётся точка отправления - склад или магазин, откуда забирают заказы. После проверки данных выдаётся OAuth-токен и идентификатор станции отправления, которые дальше идут в заголовках каждого запроса к API.

Первые тестовые запросы имеет смысл делать в песочнице: там можно создать заявку, посмотреть, как меняются статусы, и проверить обработку вебхука, не тратя реальные деньги на курьера. Я обычно держу тестовый и боевой токен в разных переменных окружения и явно логирую, какой режим используется в текущем запросе - иначе рано или поздно тестовый заказ уйдёт живому курьеру, а боевой останется висеть в песочнице.

Пример запроса на создание заявки:

curl -X POST "https://b2b.taxi.yandex.net/b2b/cargo/integration/v2/claims/create" \
  -H "Accept-Language: ru" \
  -H "Authorization: Bearer $YANDEX_DELIVERY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [{"weight": 1.2, "size": {"length": 0.3, "width": 0.2, "height": 0.15}}],
    "route_points": [
      {"type": "source", "address": {"fullname": "Склад, ул. Складская, 1"}},
      {"type": "destination", "address": {"fullname": "Адрес клиента"}}
    ],
    "client_requirements": {"taxi_class": "express"}
  }'

В ответ прилетает id заявки, дальше по нему опрашивается статус или ждётся вебхук.

Расчёт стоимости и зоны доставки на Tilda

Тильда не умеет напрямую дёргать внешний API с секретным токеном из браузера - ключ окажется виден в исходном коде страницы, и это прямой риск слить доступ к вашему кабинету отправителя. Поэтому расчёт стоимости и создание заявки всегда веду через прокси-функцию: серверлес на Vercel или обычный PHP-эндпоинт, который принимает данные из формы Тильды, дергает Яндекс Доставку от своего имени и возвращает магазину уже готовую цену.

Схема на практике такая: скрипт на странице Тильды слушает событие отправки формы заказа, забирает адрес и вес корзины, шлёт их на свой бэкенд, тот считает оффер и подставляет цену доставки прямо в блок оформления заказа до нажатия кнопки «Оплатить». Отдельно приходится городить зоны доставки - для части клиентов дешевле и быстрее считать стоимость не через API на каждый чих, а по заранее нарисованным полигонам на карте, особенно если магазин работает в паре городов и часть заказов возит своими силами. У меня в библиотеке есть готовый скрипт зон доставки для Tilda, который берёт на себя именно эту часть: сверяет адрес с зонами, подставляет цену зоны и не даёт оформить заказ вне покрытия.

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

Подключение к WooCommerce и другим CMS

На WooCommerce ситуация похожа на подключение эквайринга: например, когда я ставлю приём платежей через T‑Bank, ключи и логика запроса тоже живут на сервере, а не во фронтенде темы. С Яндекс Доставкой делаю так же - плагин или кастомный модуль подписывается на хук создания заказа (woocommerce_checkout_order_processed), собирает адрес и состав корзины, обращается к API за расчётом стоимости в момент оформления и после оплаты создаёт заявку на курьера, сохраняя её id в мета-поле заказа.

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

Если магазин на самописном движке или SPA, схема не меняется - только вместо готовых хуков WooCommerce пишется отдельный сервис, который слушает создание заказа в базе и вызывает те же методы API.

Автоматизация заявок через n8n и уведомления

Когда заказов немного и нет ресурсов на отдельный бэкенд-сервис, я собираю всю цепочку в n8n: вебхук принимает данные заказа из Тильды или CMS, HTTP Request нода считает стоимость и создаёт заявку в Яндекс Доставке, а следующая нода пишет уведомление в Telegram менеджеру о новом заказе и присвоенном треке. На настройку такой цепочки с обработкой ошибок и повторными попытками у меня уходит обычно 2-3 дня, автоматизация в n8n такого уровня стоит от 25 000 ₽.

Если логика уведомлений сложнее - клиент должен сам получать статус доставки в переписке, выбирать время подачи курьера или отменять заказ - вместо ноды Telegram в n8n ставлю отдельного бота на aiogram, который хранит состояние диалога и дергает тот же API Яндекс Доставки по запросу пользователя. Такой бот с интеграцией под ключ обходится от 30 000 ₽.

Яндекс Доставка или СДЭК: что выбрать для интеграции

Выбор между сервисами обычно упирается не в цену перевозки, а в то, как быстро нужно доставлять и насколько удобно интегрировать API в конкретный магазин.

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

Частые ошибки при подключении к API

Большая часть проблем повторяется от проекта к проекту.

• Секретный токен зашит в клиентский JavaScript на Тильде или в теме WordPress - его видно в исходном коде страницы, доступ к аккаунту отправителя утекает вместе с ним.
• Не настроен вебхук статусов - магазин узнаёт об отмене заказа курьером через час вместо нескольких секунд, клиент уже написал в поддержку с вопросом «где мой заказ».
• Тестовый токен из песочницы случайно остаётся в проде после релиза - заявки создаются, но курьер по ним не выезжает.
• Расчёт стоимости не учитывает реальный вес и габариты корзины, а берёт усреднённые значения - на крупных заказах цена доставки не сходится с тем, что выставляет API при создании заявки, и разницу магазин доплачивает из своей маржи.
• Нет обработки повторных попыток при недоступности API - на пиковой нагрузке в чёрную пятницу часть заказов просто не создаёт заявку, и это вскрывается только по жалобам клиентов.

Большинство из этого лечится на этапе тестирования, если гонять сценарий не только «happy path», но и обрывы соединения, недоступный адрес, нулевой вес корзины.

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

Сколько занимает подключение Яндекс Доставки к магазину

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

Можно ли обойтись без бэкенда и работать напрямую с фронтенда

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

Что делать, если нужна доставка и Яндекс Доставкой, и СДЭК одновременно

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

Как отслеживать статус доставки без постоянного опроса API

Нужно принимающий вебхук на своём сервере привязать к URL в личном кабинете отправителя - тогда Яндекс Доставка сама присылает уведомление при смене статуса заявки, и не приходится дергать API по расписанию вручную.