Привет, Хабр! Меня зовут Юля Анпилогова, я менеджер команды индивидуальных интеграций CDEK. Мы стали первыми, кто не только запустил интеграцию с Wildberries по схеме DBS, но и создал единую точку подключения к маркетплейсам WB и Ozon. Этот опыт оказался похож на квест. Курьеры, не привыкшие спрашивать код, лимиты запросов API Wildberries и покупательница Елена, заказавшая тестовый ежедневник — всё это оказалось его частью. Сегодня в статье расскажу, как мы прошли этот путь.
Содержание
Жёсткий дедлайн, тонна доработок и мысли, не дававшие спать
Итак, на старте нас ждал жёсткий дедлайн (2 месяца) и понимание, что помимо самой интеграции с маркетплейсом потребуется большое количество доработок в смежных командах. А точнее: новый интерфейс в мобильном приложении у курьеров и сотрудников ПВЗ, подсказки для сотрудников колл‑центра, а ещё — внедрение всех изменений.
Временами у меня возникали сомнения: «Успеем ли мы?». И ещё один более важный вопрос: «А будут ли пользоваться?». Ответ на второй вопрос пришёл из изучения болей селлеров.
Наши кастдевы показали, что рабочий процесс селлера Wildberries по схеме DBS был основан на ручном вводе заказов, переписке в мессенджерах и фотографиях кодов выдачи на листочках, которые курьеры CDEK присылали селлеру. Когда таких заказов больше 100 в день, рабочий день превращался в постоянный ручной ввод и часто предполагал создание команды сопровождения, которая занималась только этими ручными операциями. В этот момент мы осознали, что создаём что‑то действительно важное, что спасёт сотни человеко‑часов.
И действительно, очень ценной для нас была реакция селлеров. Когда они узнали, что мы работаем над интеграцией, не просто ждали релиза, а активно предлагали помощь: давали временный доступ к своим аккаунтам в личном кабинете и очень просили поскорее запустить функционал. Это стало лучшим доказательством того, что мы решали по‑настоящему важную проблему пользователей.
Испытание на прочность: внедрение
Заказы Wildberries получателям выдают по коду из приложения WB. После проверки этого кода через интеграцию маркетплейс автоматически закрывает сделку в личном кабинете селлера.
Разработать интерфейс для курьеров с полем ввода кода WB в мобильном приложении было несложно. Труднее было внедрить наши изменения «на земле»: ведь регламент выдачи заказа в CDEK предполагает выдачу по документу, а для заказов Wildberries такой опции просто не существует. И если программный код написать — дело нескольких недель, то переучить тысячи курьеров по всей стране — куда сложнее.
Для этой задачи мы решили использовать максимум инструментов. От написания инструкции в мобильном приложении для курьеров и публикации регламента до обучения на практике. Но всё равно на старте мы сталкивались с тем, что кто‑то вместо кода Wildberries просил показать документ или вовсе отдавал заказ без кода, а потом не мог закрыть доставку. Постепенно процесс наладился.
«Дырявое ведро» или как мы исчерпали лимиты Wildberries
На WB, как и положено высоконагруженному сервису, существуют жёсткие лимиты на количество запросов в минуту. Алгоритм напоминает «дырявое ведро» с токенами (Token Bucket), где можно ненадолго «ворваться» сверх лимита (burst), но потом придётся подождать. Из‑за сжатых сроков вопросы контроля лимитов отошли на второй план, что впоследствии стало нашей ошибкой.
О том, как выходили из этой ситуации, расскажет наш разработчик Дмитрий:
«Интеграция вызвала большой интерес у селлеров на маркетплейсе, и практически сразу мы стали получать достаточное количество HTTP 429 (Too Many Requests). Это прилично замедляло обработку заказов. Свою роль здесь сыграло ещё и то, что для создания заказа в системе CDEK нам требовалось сделать несколько обращений к API WB. Каждое такое обращение — это отдельный запрос в общий лимит. В итоге пришлось оперативно добавлять ограничение нагрузки с нашей стороны.
Технически можно пойти разными путями, но так как у ERP‑системы CDEK микросервисная архитектура, решение должно было уметь распределять запросы между экземплярами. Особенностью Wildberries является ещё и то, что ограничения срабатывают по каждому селлеру в отдельности. Значения всплесков и общего лимита могут динамически меняться, включая «штрафы» по некоторым статусам, которые снижают лимит сразу на 5 запросов (всё это приходит HTTP в заголовках ответа на запрос). Это делает некоторые готовые решения типа Resilience4J неудобными в применении. В итоге было принято решение создать свой инструмент на базе Redis под наши требования.
Redis хорошо подходит для хранения параметров лимитов и организации блокировок при запросах, для отложенных вызовов в силу своей отзывчивости. Алгоритм достаточно простой: тот же Token Buсket, упомянутый выше, но на стороне клиента по каждому селлеру. Начинается всё с параметров по умолчанию (burst, максимальное количество запросов в минуту, обозначенные в документации Wildberries), и далее эти параметры могут корректироваться во время ответов. Из минусов — мы получаем некоторое возможное количество ожидающих своего времени потоков. Но это не вызывает каких‑то проблем с учётом текущих лимитов и количества активных заказов на маркетплейсе. В дальнейшем решение будем дорабатывать и оптимизировать.
Наглядное решение проблемы можно наблюдать на сводном графике, где запрос метаданных по каждому продукту (который всегда проходит после опроса статуса заказа и как правило, уже не попадает в отведённый burst) стал работать как полагается.»
Как наш тестовый заказ купила незнакомая Елена
Неожиданный случай произошёл во время теста интеграции на Ozon realFBS. В качестве тестового товара был выбран ежедневник. Пока мы с коллегами делали первые заказы, нам пришло сообщение, что первый интегрированный заказ создан. Успех! Смотрю и не понимаю… У нас в команде нет ни одной Елены, а получателем указана именно она.
Оказалось, что пока мы с коллегами покупали наши ежедневники, карточку товара увидел самый шустрый покупатель страны. Реальный человек, который просто хотел себе новый ежедневник. Улыбаюсь и решаю непременно отправить Елене ежедневник и открытку. Подписала открытку, в которой поблагодарила её за «незапланированное тестирование нашего сервиса», и отправила ей этот ежедневник.
Елена, если вы это читаете — вам сердечный привет от всей нашей команды! Спасибо, что стали нашим первым и самым неожиданным тестировщиком.
Инструкция для селлеров на GitHub: почему бы и ДА
Когда интеграция с маркетплейсом уже была готова, возник вопрос: как сделать так, чтобы селлерам было легко и удобно её настроить? Первоначально мы планировали сделать PDF‑файл с инструкцией в личном кабинете CDEK, откуда как раз можно подключить интеграцию с маркетплейсом.
Проанализировав, мы поняли: это не очень удобно. Поэтому было решено делать инструкцию для селлеров прямо в GitHub. Этот вариант оказался удобнее, так как его легко редактировать и обновлять, а также он хорошо читается с любого устройства.
Результаты и выводы
Тот самый пугающий «дедлайн вчера» стал нашим главным мотиватором. Мы не просто успели, но и получили отличные результаты за период с мая по ноябрь 2025 года:
• 1000+ подключенных магазинов к интеграции
• 55 000+ заказов было обработано через интеграцию.
Итак, выводы:
Не верьте в «простое API» — за каждой интеграцией стоят люди и процессы. Нужно быть готовым менять не только код, но и регламенты.
Найдите свои «салфеточные коды». Проведите кастдев и поймёте, как пользователи работают и с какими болями сталкиваются.
Лимиты внешнего API — архитектурный враг № 1. Учитывайте их с самого начала, не откладывая на потом.
Тестовый заказ может купить реальный покупатель. И это нормально, если вы к этому готовы.
А с какими сложностями при интеграции сталкивались вы? Делитесь в комментариях.