API Почты России переносит заказ магазина в отправку, а агенты собирают и проверяют связку

Почта России уже сделала интерфейс для подготовки отправлений. Через «Отправку» можно создавать заказы, готовить ярлыки и документы, формировать партии, проверять адреса. Созданная запись в кабинете ещё не означает, что посылку приняли в отделении.

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

Запрос «подключить API Почты России» слишком широк для приёмки. Расчёт доставки в корзине, оформление отправления и история его движения — разные результаты. Выберите тот, из-за которого сотрудники сегодня повторно набирают данные.

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

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

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

Магазин задаёт свой номер, «Отправка» присваивает внутренний идентификатор и штрихкод отправления. Они связывают одну отгрузку между системами, но не заменяют друг друга. Показать сотруднику только «отправлено» недостаточно: он должен открыть именно её запись.

Версии метода создания различаются. В первой документирован список успешных внутренних идентификаторов; во второй у созданного заказа возвращаются order-num, result-id и barcode. Разработчик выбирает версию явно и сохраняет соответствие по её контракту, а не разбирает ответ по примеру из случайной библиотеки.

После создания магазин проверяет, что вернувшийся номер относится к ожидаемой отгрузке, и записывает идентификаторы вместе. Если запись результата в магазине сорвалась, заказ остаётся для сверки. Статус «создано» появляется после сохранённого результата, а статус физической доставки требует истории операций.

Ответ создания содержит сведения об ошибках и успешно созданных заказах. Поэтому общий ответ сервера нельзя превращать в «вся пачка отправлена»: каждый элемент получает собственный результат. Оператору нужны номер заказа, причина и действие, которое он может выполнить.

Тайм-аут — другой случай. Магазин не получил ответ, но сервис мог успеть создать заказ. Автоматический повтор без сверки рискует создать ещё одну запись; в просмотренных разделах документации мы не нашли гарантии, что одинаковый запрос безопасно повторять сколько угодно.

До сетевого вызова связка фиксирует попытку, а после неизвестного исхода ищет созданную запись и сверяет её. В API есть поиск по назначенному магазином номеру. Если результат нельзя установить, заказ ждёт решения оператора; отсутствие ответа не превращается в зелёный статус.

В этой задаче ИИ не нужен между каждым покупателем и Почтой России. Агенты пишут код интеграции и тесты в репозитории, а готовая программа передаёт данные по заданным правилам. Постановка задач начинается с примеров ответа и результата «готово», а не с команды «сделай интеграцию».

Мы проверили на своём сайте, как легко потерять поле при передаче между этапами. В июле описание сцены обложки вручную перечислялось в нескольких местах, и часть путей его не передавала. Это ошибка согласованности данных; она сама по себе не объясняла отсутствие новых обложек.

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

Инженер ведёт машину агентов на vibecoding.ru; открытая стройка показывает её работу. Это основание обсуждать правила, задачи и проверки. Оно не даёт нам права обещать магазину измеренную экономию или ссылаться на несуществующую доставку нашего клиента.

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

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

На 8 октября 2026 года подписка на разработку «Один проект» стоит 250 000 ₽ в месяц. Инженер с машиной ИИ-агентов может вести передачу заказов, проверку адресов, разбор ошибок и сверку идентификаторов в репозитории клиента. Это предмет работы, а не утверждение, что связка уже сделана или уложится в месяц.

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

Если подходящий модуль уже передаёт заказы, подписка ради его установки может не понадобиться. Своя связка имеет смысл, когда разрыв остаётся в вашем коде и дальше его предстоит развивать. Для следующего шага передайте список ручных операций и пример обезличенного заказа через страницу для руководителя.

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

Перед приёмкой покажите ошибку адреса, частичный отказ, повтор и потерянный ответ. Попросите найти заказ с обеих сторон и объяснить, что сделает оператор. Открывающийся экран без этих сценариев ещё не подтверждает, что ручной перенос закончился.

После запуска смотрите, сколько заказов не завершили передачу, сколько потребовали ручного исправления и где разошлись идентификаторы. У каждого исключения есть ответственный и разбор причины; повторяющаяся причина становится правилом или проверкой. Так ошибка возвращается в разработку, а интеграция перестаёт быть кнопкой, за которой нужно следить вручную.