LaaS-возврат через API Яндекс Маркета оформляется для доставленного заказа после проверки подходящего пункта выдачи. Наличие ПВЗ на карте само по себе не означает возможность сдать туда конкретные товары. Ниже — порядок регистрации обращения, проверенный по справке 18 октября 2026 года.

Начать с заказа и фактического состава

Метод создания возврата доступен для LaaS и требует статуса заказа DELIVERED. Для продавцов Market Yandex Go он пока недоступен. Это отдельная операция обратной логистики; она не заменяет создание исходного заказа и не относится автоматически ко всем моделям торговли Маркета.

До вызова API сотруднику стоит сопоставить обращение с номером доставленного заказа: какие SKU возвращают, в каком количестве и по какой причине. Если покупатель получил несколько единиц, не копируйте первоначальный состав целиком без проверки. Такой контроль особенно важен при общем стоке FBY и LaaS, где складской остаток и обращение по конкретной покупке решают разные задачи.

Проверить пункт выдачи для выбранных товаров

Запрос return-delivery-options принимает состав возврата с offerId и count, а также перечень проверяемых ПВЗ в pickupDelivery.logisticPointsIds. В одном таком перечне допускается до 20 уникальных идентификаторов. Ответ содержит подходящие пункты в pickupDelivery.logisticPointIds — обратите внимание на различие написания полей запроса и ответа.

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

Зарегистрировать обращение с согласованной причиной

Создание выполняется через POST v1/campaigns/{campaignId}/returns/create. В newReturn передаются внешний номер externalReturnId, orderId, товары, данные отправителя и выбранный пункт в returnOption.pickupReturn.logisticPointId. Для каждой позиции используются причина reasonType и её уточнение subreasonType; справка разделяет брак, неподходящий товар и получение другого товара.

Не копируйте пример JSON механически: уточнение должно соответствовать выбранной причине и словам покупателя. Комментарий помогает объяснить обстоятельства, а фотографии — зафиксировать состояние. Обработка доступных решений по возврату является отдельной задачей: регистрация перевозки сама по себе не доказывает, что спор уже разрешён или деньги перечислены.

Связать два номера и проверить результат

В успешном ответе создания возвращается id заявки. Сохраните его рядом с externalReturnId и исходным orderId. Это позволит поддержке отличать номер обращения в своей системе от номера возврата Маркета и находить нужную запись при повторном контакте покупателя.

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