Cценарий в Make.com отслеживает статусы посылок через CDEK API и шлёт клиентам уведомления | Марина Погодина, PROMAREN
По состоянию на февраль 2026 CDEK API уже давно не только про «создать накладную». Это удобный способ заставить доставку работать без ручного трекинга и прозвонов, особенно если подружить его с Make.com. Я покажу, как за полчаса собрать живой сценарий: трекинг посылок, уведомления и спокойный отдел поддержки.
Обновлено: 7 февраля 2026
Время чтения: 12-14 минут
- Что такое CDEK API и зачем он вам
- Как настроить автоматический трекинг посылок
- Что учесть в уведомлениях клиентам через API
- Как подключить CDEK API к сайту и CRM
- Типичные грабли и как не сломать автоматизацию доставки
В начале 2026 я поймала себя на привычном движении: открыть вкладку СДЭК, вбить трек, сделать скрин клиенту в мессенджер. Через двадцать минут кофе уже остыл, а я всё ещё играю «ручной трекер». В этот момент и родились первые сценарии на Make — сначала кривые, зато они наконец начали делать эту рутину за меня.
Теперь в PROMAREN мы ставим интеграции с CDEK API клиентам по одному и тому же принципу: никакой магии, только честная архитектура под задачи бизнеса и под реалии РФ. Про тонкости 152-ФЗ здесь можно не переживать, но про прозрачность процессов и логов забывать точно не стоит.
Что такое CDEK API и зачем он вам
3 из 5 магазинов, с которыми я работаю, используют CDEK API только на 30% возможностей — создают заказы и всё. Остальные 70% лежат нетронутыми: трекинг посылок в реальном времени, статусы, уведомления, списки ПВЗ, всё это можно забирать и крутить в Make.com.
CDEK API — это интерфейс службы доставки СДЭК, который даёт доступ к операциям вроде создания заказов, расчёта тарифов, трекинга и получения статусов по REST-запросам. По сути вы разговариваете с СДЭКом на языке JSON: отправляете запросы на защищённые эндпоинты, а в ответ получаете структурированные данные, с которыми уже могут работать сценарии автоматизации.
Чтобы к этому вообще подступиться, нужен действующий договор с СДЭК, аккаунт и пара токенов в личном кабинете. Авторизуемся под админом, включаем API, создаём учётку интеграции — это тот самый логин/пароль, который потом меняется на access token по протоколу OAuth. Официальная документация доступна на портале разработчика CDEK, там же лежат примеры запросов и ответов JSON, которые удобно прогонять через Postman до того, как вы всё это потащите в Make.
Ключевая ценность CDEK API в том, что он отдаёт не только финальный статус, но и живую историю движения: status_code, дату изменения, город, иногда даже комментарии. Эти поля отлично ложатся в сценарии Make: их можно фильтровать, сохранять в таблицу, поднимать как триггеры уведомлений. По данным самой компании, API используют уже тысячи интернет-магазинов в РФ, потому что без этого при объёме хотя бы 50 отправок в день менеджеры просто тонут в ручных проверках.
Make платформа здесь выступает как no-code прослойка между вашим сайтом, CRM и CDEK API: одни модули отправляют запросы, другие принимают вебхуки со статусами. По опыту PROMAREN, для базовой интеграции достаточно стандартных HTTP-модулей и встроенных инструментов работы с JSON, без кастомного кода и серверов. Да, можно добавить коннекторы вроде ApiMonster, но это уже надстройка, а не обязательная часть.
У CDEK API, как и у любого живого сервиса, есть лимиты по запросам и требования к безопасности. Токен лучше хранить в переменных или connection-секретах Make, а не вшивать в каждый модуль — и уж точно не копировать его в скриншоты с обучением. В 2025-2026 по данным Gartner автоматизация логистики даёт e-com прирост эффективности до 3-5 раз, просто за счёт того что люди перестают трекать вручную и передёргивать статусы по телефону.
Это означает, что CDEK API превращается из «галочки в чеклисте» в реальный рычаг — особенно, когда вы начинаете строить поверх него связки с CRM и кассой. Как только базовое понимание API появилось, логично перейти к самому вкусному — автоматическому трекингу посылок, который и снимает половину боли с операционки.
Как настроить автоматический трекинг посылок без кода
Автоматический трекинг через CDEK API в Make обычно укладывается в 25-30 минут: один вебхук, пара HTTP-запросов и простая логика фильтров. Если не пытаться сразу строить «идеальную систему», а начать с минимального рабочего сценария — результат будет уже сегодня, а не «как-нибудь потом».
В 2026 я почти всегда собираю такую связку одинаково: CDEK отправляет обновления статусов на вебхук Make, сценарий парсит JSON, фильтрует нужные коды состояний и записывает всё в хранилище. Для небольших магазинов удобно использовать Google Sheets, для более плотной работы — Airtable или базу внутри CRM. Трекинг по запросу (pull) через /orders/{cdek_number} оставляем как запасной вариант, если вебхуки по каким-то причинам недоступны или нестабильны.
Как выглядит базовый сценарий трекинга в Make.com
Сценарий трекинга начинается с вебхука: в Make создаём модуль Webhooks → Custom webhook, получаем уникальный URL и прописываем его в личном кабинете CDEK как адрес для уведомлений. Как только статус по заказу меняется, CDEK шлёт на этот URL JSON с полями вроде cdek_number, status_code, city_name, status_date_time. В следующем модуле добавляем парсер JSON или сразу работаем с атрибутами, если Make их уже распознал, и настраиваем фильтры: например, пропускать только статусы «вручено», «возврат» и «курьер в пути». Дальше подключаем блок записи — Google Sheets Add row или Airtable Create record — и сохраняем трек-номер, статус и дату. На практике такой сценарий реально собирается за один присест, если под рукой уже есть тестовый трек-номер и доступ к CDEK ЛК.
Нужен ли трекинг по запросу и когда его включать
Иногда вебхуки по CDEK API недоступны из-за ограничений инфраструктуры или политики безопасности, и тогда приходится идти по пути опроса — дергать эндпоинт статусов по расписанию. В Make это решается модулем Scheduler, который раз в N минут берёт список активных отправлений из таблицы и для каждого делает HTTP GET на /orders/{cdek_number}. Ответ с историей статусов парсится, дальше можно выбирать последний по дате и обновлять запись в хранилище. Такой вариант менее экономичный по запросам и иногда упирается в лимиты CDEK, зато полностью контролируемый с вашей стороны. В одном из проектов PROMAREN мы именно так обходили нестабильные вебхуки: да, сценарий получился чуть сложнее, зато трекинг не падал, когда у клиента менялась внутренняя сеть.
Где хранить статусы и как не утонуть в таблицах
Трекинг — это не только про «получить статус», но и про то, как удобнее с ним потом жить. На старте лучше использовать простой инструмент, который уже знаком команде: Google Sheets или Excel Online, чтобы не устраивать революцию в процессах. В таблице достаточно 5-7 колонок: дата события, трек, текущий статус, город, комментарий, источник (вебхук или запрос), плюс ссылка на заказ в CRM. Если объём заказов растёт, можно мигрировать на более серьёзное хранилище, но логика сценария в Make при этом почти не меняется. Я поняла, что автоматизация трекинга работает только тогда, когда менеджер может за 10 секунд открыть нужную строку и объяснить клиенту, где его посылка, а не когда данные красиво лежат в недоступной никому базе.
К этому же сценарию обычно логично прикрутить следующий слой — уведомления клиентам о ключевых изменениях статуса. И вот там уже начинаются интересные вопросы про тонкую грань между полезной информацией и раздражающим спамом.
Что учесть в уведомлениях клиентам через CDEK API
Уведомления по CDEK API дают до 30% снижения входящих «Где моя посылка?», но только если отправлять их дозированно и в нужные моменты. Make позволяет собрать эту логику аккуратно: одно событие — одно понятное сообщение, без заливания клиента десятком почти одинаковых статусов.
Сама СДЭК уже умеет присылать SMS и звонки, если в заказе включены сервисы вроде NOTIFY_RECIPIENT или CALL. На практике я часто использую их как резервный канал, а основной выношу в свой контур: почта, мессенджеры, пуши, чтобы сообщения были в одном стиле бренда. В сценарии Make уведомления становятся финальным шагом после трекинга: сценарий проверяет статус, достаёт контакт из CRM и выбирает подходящий канал, хоть Telegram, хоть e-mail.
Как построить логику уведомлений, чтобы не заспамить
Минимальный набор статусов, на которые имеет смысл реагировать автоматически, обычно одинаковый: заказ создан, передан в доставку, прибыл в пункт выдачи, вручён, оформлен возврат. В Make это удобно собирать через роутер: на входе статус из CDEK API, дальше ветвление по кодам и у каждой ветки свой текст сообщения. Для e-mail используем модуль SMTP или интеграцию с почтовым сервисом, для мессенджеров — соответствующие коннекторы. Я всегда добавляю простое правило: не больше трёх уведомлений на один заказ, всё остальное остаётся в CRM или в личном кабинете, чтобы клиент не начал блокировать отправителя.
Какие каналы доставки уведомлений проще всего подключить
Самый быстрый старт в 2026 — связка CDEK API, Make и почты: она работает стабильно, не требует отдельного согласия на мессенджеры и укладывается в ожидания клиентов. Чуть сложнее подключаются SMS через локальных провайдеров вроде SMS.ru или специализированных шлюзов — в Make это выглядит как обычный HTTP-запрос с нужными параметрами. Мессенджеры дают больше гибкости и реакции, но уже требуют аккуратной работы с согласием и политикой конфиденциальности, особенно если вы к ним подтягиваете ещё и данные из CRM. Я бы начинала с одного надёжного канала и уже потом добавляла второй-третий, а не пыталась объять всё сразу, иначе отладки уйдут недели.
Где хранить шаблоны и как их поддерживать в актуальном виде
Шаблоны сообщений удобнее держать не вшитыми в модули Make, а в отдельном хранилище: таблица, Notion, собственный микросервис — вариантов масса. Тогда правки текста или локализации не требуют лезть в сценарий и заново прогонять все тесты, особенно когда подключены несколько языков или брендов. В одном проекте PROMAREN мы перевели шаблоны в Google Sheets: сценарий по ключу статуса подтягивает нужный текст, подставляет переменные вроде имени и даты и уже готовый текст отправляет клиенту. Да, на настройку ушло не полчаса, а пару дней, но зато маркетинг теперь может менять формулировки без участия разработчиков и интеграторов.
Когда уведомления более-менее устаканились, обычно появляется следующий запрос — «а давайте уже подключим CDEK API к нашему сайту напрямую, чтобы трек и статус подхватывались автоматически». Вот здесь Make становится тем самым универсальным мостом между витриной, CRM и логистикой.
Как подключить CDEK API к сайту и CRM через Make
Если у сайта уже есть форма заказа, подключение CDEK API через Make чаще всего занимает не дни, а несколько часов — большую часть времени съедают согласования полей, а не сама интеграция. Сайт становится источником данных, Make — транспортером, CDEK API — конечной точкой, где рождается накладная и трек-номер.
Тут помогает мыслить не «интеграция ради интеграции», а конкретным бизнес-сценарием: клиент оформил заказ на сайте, система создала заказ в CRM, потом в CDEK, вернула трек-номер и записала его туда же. Вся эта цепочка может крутиться в одном сценарии Make, без ручного копирования адресов и телефонов.
Какие этапы нужны, чтобы связать сайт, CRM и CDEK API
На практике я делю связку на три логических блока: приём данных с сайта, создание заказа в CRM и создание отправления в CDEK через API. На входе Make получает вебхук от сайта или CMS: имя, телефон, адрес, состав заказа. Следующим модулем создаём или обновляем сделку в CRM (Bitrix24, amoCRM, что там используется), чтобы заказ не потерялся. После этого сценарий формирует структуру JSON под требования CDEK API — адрес, тариф, тип доставки, ПВЗ или курьер — и отправляет HTTP POST на соответствующий эндпоинт. В ответ прилетает cdek_number и дополнительные данные, которые мы сохраняем обратно в CRM и при необходимости показываем клиенту в интерфейсе сайта.
Где взять спецификации и как не ошибиться в полях
Самый надёжный источник правды по структуре запросов — официальная документация CDEK на портале разработчика, а не устаревшие статьи двухлетней давности. Там же лежат примеры тела запроса и ответы, которые удобно прогонять через Postman перед тем, как оборачивать всё в HTTP-модуль Make. При построении интеграции в PROMAREN я почти всегда делаю маленькую таблицу-соответствие: поле в форме сайта, поле в CRM, поле в JSON для CDEK API. Это банально снижает количество «ой, забыли дом» и «а куда положим код ПВЗ». По требованиям законодательства о персональных данных в РФ (152-ФЗ) важно, чтобы по пути от сайта до CDEK данные шли через допустимые для вас площадки — здесь как раз пригодится методика white-data PROMAREN, где мы заранее фиксируем, какие сервисы можно использовать.
Как организовать логирование и откат, когда что-то пошло не так
Интеграции доставки редко живут без сбоев, поэтому стоит сразу заложить простую систему логов и повторов. В Make это реализуется через отдельную ветку сценария: если HTTP-запрос к CDEK возвращает ошибку или неуспешный статус-код, запись уходит в таблицу «ошибки доставки» с деталями. Там же можно хранить флаг «повторить позже» и настроить отдельный сценарий, который раз в час пробует отправить такие заказы ещё раз. Автоматизация без нормальных логов превращается в чёрный ящик, и тогда при первом же затыке сотрудники возвращаются к ручному созданию накладных. Лучше потратить лишний час на продуманную схему мониторинга, чем потом сутками разбираться, куда исчезли три десятка отправлений.
Когда база подключена, логирование выстроено и команда уже успокоилась насчёт надёжности, наступает время поговорить о скучном, но спасительном — о граблях. Они, как водится, всегда рядом и поджидают даже аккуратные команды.
Типичные грабли CDEK API в Make и как их обойти
90% проблем в интеграциях CDEK API с Make, которые я видела в 2025-2026, приходят не из самого API, а из спешки и отсутствия явных правил. Не задали лимиты, не проверили статус, забыли про тестовый контур — и вот уже сценарий шлёт сотни запросов впустую, а вебхуки тихо падают.
По опыту PROMAREN, спасает не «гениальная архитектура», а скучный чек-лист, который вы проходите каждый раз, когда настраиваете новый сценарий доставки. И да, это тот редкий случай, когда немного бюрократии экономит деньги и нервы.
Какие ошибки встречаются чаще всего и как их ловить
Самые частые грабли выглядят слишком приземлённо, чтобы их уважать — и поэтому в них так легко наступить снова. Сюда попадает отсутствие отдельного тестового сценария: всё сразу делается на боевых данных, а потом клиенты получают учебные уведомления и странные статусы. Вторая классика — игнор лимитов CDEK API, когда трекинг по запросу крутится без кеширования и за пару часов вылетают квоты. Третья зона риска — хранение токенов в явном виде, в комментариях или скринах, что уже попадает в поле внимания службы безопасности. Хотела написать, что это быстро чинится чинится это обычно болезненно, особенно когда уже прилетел запрос от службы комплаенса.
Какой минимальный чек-лист стоит пройти перед запуском
Здесь работает короткий, но полезный набор проверок, который мы в PROMAREN используем почти автоматически. Сначала убеждаемся, что у каждого сценария есть тестовый дубль, работающий на песочнице или хотя бы на черновых заказах. Дальше проверяем, что все HTTP-модули обрабатывают и неуспешные статусы, а не только «200 ОК», и что ошибки попадают в логи. Отдельным пунктом идёт валидация персональных данных: какие поля проходят через Make, какие действительно нужны CDEK, и что нигде не тащатся лишние паспорта и комментарии. Завершаем проверкой лимитов и частоты запусков, чтобы ночной крон внезапно не уронил интеграцию серией бездумных запросов.
Когда пора переписать сценарий, а не латать его дальше
В какой-то момент сценарий трекинга и уведомлений превращается в Frankenstein workflow: новые ветки, куча исключений, десяток разных шаблонов сообщений. Если при взгляде на схему в Make вы уже не можете объяснить за пять минут, как она работает, это сигнал подумать о рефакторинге. Обычно я предлагаю клиентам остановиться, зафиксировать, какие именно сценарии реально используются, и собрать их заново в более чистой архитектуре. Проще один раз переосмыслить структуру, чем бесконечно впаивать новые костыли в сценарий, который изначально строился как временное решение. В долгую такая тактика не только удобнее, но и дешевле — особенно когда команда меняется, а передавать «эту красоту» уже некому.
После такого разбора интеграция с CDEK API перестаёт казаться чем-то сложным и страшным: это просто ещё один сервис в вашем ландшафте автоматизации. А дальше уже можно смело двигаться в сторону более сложных связок — от AI-подсказок по логистике до автоматических расчётов SLA, но это история для отдельного разговора 🙂
Несколько мыслей напоследок про CDEK API и Make
Я поняла для себя простую вещь: как только трекинг посылок и уведомления уезжают в связку CDEK API + Make, логистика перестаёт быть ежедневным пожаром. Освобождается по два-три часа в день, и это не пустая цифра, а очень конкретные звонки, письма и переписка, которые теперь делает сценарий. Автоматизация доставки начинает работать на бизнес только тогда, когда она прозрачна, логируема и не завязана на одном «человеке, который всё знает», и здесь Make даёт как раз этот уровень управляемости. Если хочется докрутить интеграции дальше, в блоге PROMAREN уже лежат разборы по n8n, Cursor и другим инструментам, которые спокойно живут рядом с CDEK и помогают выстроить общий контур автоматизации.
Обо мне. Я Марина Погодина, основательница PROMAREN и AI Governance & Automation Lead. С 2024 года помогаю в РФ строить автоматизацию на Make, n8n, Cursor, внедряю интеграции доставки и AI-агентов. Пишу разборы в блоге PROMAREN и делюсь живыми кейсами в канале PROMAREN.
Если хочется разобрать свою схему доставки или трекинга, можно начать с материалов по автоматизации через n8n и Make. Для тех, кто уже созрел на более плотную связку с сайтом, у меня есть формат «лендинг на Cursor с интеграцией CRM и доставкой» на сайте PROMAREN, а тестовый доступ к ботам можно получить через демо-бота (нет, лучше скажу иначе: просто зайдите и посмотрите, что там уже умеет делаться само).
Что ещё важно знать про CDEK API и Make
Можно ли обойтись без Make и интегрировать CDEK API напрямую?
Технически можно подключить CDEK API напрямую к сайту или CRM, если у вас есть разработчики и доступ к коду. Но Make снимает большую часть рутины: не надо поднимать сервер, следить за обновлениями библиотек и писать обработчики ошибок с нуля. Для малого и среднего бизнеса это часто дешевле и быстрее, а при росте нагрузки всегда можно вынести часть логики в кастомный бэкенд, оставив Make как оркестратор.
Что делать, если вебхуки CDEK не доходят до сценария Make?
Если вебхуки не доходят, сначала проверьте, правильно ли скопирован URL вебхука из Make в личный кабинет CDEK и не менялся ли он при правке сценария. Затем загляните в логи Make: там видно, были ли входящие запросы и с какими кодами ответов. Если вообще тишина, проверьте настройки сети и возможные блокировки, а в крайнем случае временно переходите на трекинг по запросу с расписанием. Такой режим менее удобен, но позволяет не останавливать бизнес-процесс, пока вы ищете причину.
Нужен ли отдельный тестовый контур для интеграции CDEK API?
Да, тестовый контур очень желателен, особенно если вы часто меняете сценарии или подключаете новые статусы и уведомления. Минимум, который стоит сделать, — отдельный сценарий Make, работающий с тестовыми заказами и отправляющий уведомления только на ваши адреса. Это позволяет безопасно проверять изменения логики, не трогая живых клиентов. По мере взросления проекта можно завести отдельный аккаунт CDEK для песочницы, чтобы ещё и финансовые риски свести к нулю.
Как контролировать расходы на Make при активном трекинге посылок?
Контроль расходов строится вокруг количества сценариев и частоты запусков: чем больше уведомлений и опросов API, тем выше счёт. Начните с оценки среднего числа заказов и статусов, от этого посчитайте примерное количество операций в Make и подберите тариф. В сценариях избегайте лишних циклов и дублирующих запросов, используйте кеширование, если это возможно. И не забывайте раз в месяц смотреть статистику использования в аккаунте Make, чтобы вовремя заметить аномальный рост нагрузки.
Можно ли комбинировать CDEK API с другими службами доставки в одном сценарии?
Комбинировать разные службы доставки в одном сценарии не только можно, но и полезно, если у вас несколько логистических партнёров. Make позволяет настроить роутинг по полю «служба доставки» и для каждого варианта использовать свои HTTP-модули и логику статусов. Главное — заранее выровнять структуру данных в CRM, чтобы не плодить десятки полей под каждую службу. Тогда отчёты и уведомления останутся единообразными, а вам будет проще поддерживать такую архитектуру в долгую.