Вебхуки СДЭК отключаются сами: статусы перестали приходить

Посылки едут, а статусы в системе стоят

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

Причина чаще всего в правилах самой подписки. Та же история с МойСклад описана в статье про молчаливую потерю заказов, здесь разбор для СДЭК. Правила я проверял в начале октября 2026 в документации на apidoc.cdek.ru, в разделе про вебхуки.

Что СДЭК делает с подпиской

СДЭК сам шлёт POST с JSON на ваш адрес, когда у заказа меняется статус (тип события ORDER_STATUS). Есть и другие типы: PRINT_FORM для готовой печатной формы, ORDER_MODIFIED, DELIV_PROBLEM, COURIER_INFO и ещё несколько. В документации написано следующее.

Из таблицы три следствия. Любой ответ, кроме 200, считается сбоем, даже если вы просто не успели обработать событие. Хватает долгого простоя сайта: деплой, перегруженный хостинг, упавшая база. Сколько событий нужно для 12 попыток, зависит от интервала повторов, а его документация не называет. Третье следствие касается дублей: если подписка с таким типом уже есть, повторное создание добавляет ещё одну подписку, прежняя остаётся, и лимит в две подписки на клиента расходуется быстро.

Увидеть пропажу можно двумя способами. Метод получения информации о подписках отдаёт все активные. Если в списке нет вашего адреса, подписки нет. Вторая проверка проще: храните время последнего принятого события и поднимайте тревогу, если в рабочее время при заказах в пути событий не было несколько часов. Похоже работает сторож в одном из моих ботов: он раз в 2 минуты смотрит метку времени планировщика, и если она старше 180 секунд, перезапускает бота и пишет администраторам, но одну проблему не чаще раза в час.

Надёжный приёмник: 200 быстро, работа в очереди

Приёмник должен делать минимум и делать это за доли секунды. Порядок такой.

1. Принять POST и сохранить тело как есть в таблицу событий, не разбирая его глубоко.

2. Сразу ответить 200. Всё, что требует базы, CRM или внешнего API, уходит в очередь и выполняется отдельным воркером. Если воркер упал, это ваша проблема внутри системы, а СДЭК получил 200 и подписку не тронул.

3. Сделать приём идемпотентным. В событии ORDER_STATUS есть type, uuid заказа, код статуса в attributes (поле code) и время установки статуса (status_date_time). Из них можно собрать ключ и записывать событие один раз. Уникального идентификатора самого события я в документации не нашёл, так что ключ придётся собирать из этих полей. Повтор тогда ничего не ломает: тот же ключ просто игнорируется.

4. Не полагаться на порядок: гарантий порядка доставки в документации нет, поэтому сравнивайте время статуса и не затирайте новый старым.

5. Повторять свои исходящие вызовы по тому же принципу. В боте у меня отправка делает три попытки и при ответе «подождите» ждёт указанное время плюс секунду. Такая обвязка описана в статье про поддержку ботов и интеграций.

Приёмник удобно вынести на отдельный маленький сервис, чтобы релиз сайта и нагрузка магазина его не задевали. На мусорный запрос тоже отвечайте 200 и пишите ошибку разбора в журнал, иначе подписка попадёт под удаление.

Ночная сверка статусов

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

1. Выберите заказы, которые не в статусах DELIVERED и NOT_DELIVERED: документация помечает их как конечные.

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

3. Сравните статус с вашим. Если отличается, обновите и пометьте в журнале, что поправила сверка, а не вебхук. Если сверка регулярно что-то правит, вебхуки снова отключены.

4. Шлите запросы спокойно. Для всех методов API СДЭК указал порог гарантированной обработки в 200 запросов в секунду, поэтому для сверки хватит единиц запросов в секунду.

5. Если в списке подписок нет вашего адреса, создайте подписку заново и отправьте тревогу владельцу.

Передачу треков и статусов в учётную систему разбирает статья про заказы из Tilda и WordPress, а вопрос «кто виноват» статья про поломки интеграций.

Границы и что сделать сегодня

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

Что сделать сегодня:

1. Запросите список подписок и убедитесь, что ваш адрес в нём есть и подписок не больше двух.

2. Проверьте, как ваш адрес отвечает на тестовый POST: должен быть 200 за доли секунды, а не 15.

3. Включите хранение времени последнего события и тревогу при долгом молчании.

4. Заведите ночную сверку, пусть сначала просто пишет расхождения в журнал. Основа цепочки описана в статье про автоматическую передачу заказов в доставку. Сам контур подписки с очередью и сверкой я собираю в автоматизации логистики.

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

Сколько подписок можно создать?

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

Подписку отключили. Что делать?

Создать заново после того, как приёмник починен, и сразу прогнать сверку по заказам без конечного статуса. Так закроются пропуски за время простоя. Порядок восстановления в документации не описан.

Можно ли обойтись без вебхуков и только сверять?

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

Коротко о главном

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

Хотите, чтобы я проверил ваш приём вебхуков СДЭК, поставил очередь и сверку и настроил тревогу при молчании? Напишите мне в Telegram слово «ВЕБХУКИ».