Яндекс Маркет добавил API документов: что проверить в обмене

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

Что объявлено в сентябрьском обновлении

В публичном сообщении команды API перечислены создание, обновление, удаление и получение документов на товары. В тексте указано 9 сентября, время публикации подтверждает сентябрь 2026 года. Для создания, обновления и удаления объявлены пакеты до 100 документов; получение описано с фильтрами и постраничной загрузкой.

Это повод убрать ручной перенос реквизитов из процесса продавца, но сначала нужно определить источник данных. Кто подтверждает номер, тип и даты, какая версия считается актуальной и кто исправляет расхождение? Без этих решений массовая передача лишь быстрее разнесёт несогласованные сведения.

Созданные записи и ошибки возвращаются раздельно

В справке createDocuments предусмотрены созданные документы и ошибки обработки. Ошибка одного документа не мешает остальным. Но повторяющиеся номера внутри одного запроса — отдельный случай: по документации такой запрос не обрабатывается.

Поэтому проверяйте сначала допустимость всего подготовленного пакета, затем результат каждой исходной записи. Не ставьте всем строкам отметку «готово» только по общему HTTP-ответу. Для учебного примера возьмём три разных исходных документа без реальных реквизитов.

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

Номер документа и идентификатор записи — не одно

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

Справка создания отдельно описывает привязку к товару через номер в поле certificates метода работы с offer-mappings. Само создание записи документа не следует выдавать за завершение всех связей каталога. В приёмке раскройте путь от исходного документа до нужного товара, сохраняя границы разных операций.

Обновление полностью заменяет реквизиты

Метод updateDocuments полностью обновляет номер, тип и даты. Для каждого документа передаются идентификатор и актуальные значения; если дату не указать, прежняя сохранённая дата удаляется. Здесь нельзя без проверки применять привычную логику «отправим только изменённое поле».

В собственной системе заранее различите неизвестную дату и намерение убрать прежнюю. Перед формированием обновления соберите актуальную версию всех нужных реквизитов. Если данных не хватает, строку лучше передать ответственному на проверку, чем молча очистить значение.

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

Как принять обмен с учётной системой

1. Определите источник подтверждённых реквизитов и ответственного за исправления.
2. Проверьте состав пакета и отсутствие повторных номеров внутри него.
3. Разберите отдельно созданные документы и ошибки каждого элемента.
4. Сохраните связи исходных записей, номеров и идентификаторов площадки.
5. Проверьте привязку к товарам отдельно от создания документа.
6. Проверьте полное обновление, сохранение дат и намеренное удаление даты на учебных данных.
7. После обмена сверяйте состояние, а не только наличие успешного запроса.

Не делайте из этой схемы универсальный юридический список документов для любого товара. Требования зависят от конкретной ситуации и проверяются отдельно. Наличие записи API не доказывает само по себе действительность сертификата и соответствие всей продукции.

Для интеграции с 1С передайте правила исходной версии и сопоставления. В автоматизации процессов согласуйте разбор исключений, а при доработке обмена начните с частичного результата и поведения дат. Реальные документы, токены и операции создания в рамках статьи не использовались.