Заявление на возврат — отдельный документ в истории заказа. Для магазина важно не просто скачать PDF, а сохранить его под правильной заявкой, проверить содержимое и связать с дальнейшим рассмотрением. Такое правило особенно полезно, если один заказ включает несколько товаров и обращения по ним поступают в разное время.

Какой документ выдаёт API

Метод getReturnApplication возвращает PDF заявления покупателя. В адресе запроса указывают campaignId магазина, orderId заказа и returnId возврата. Метод доступен для FBY, FBS, Экспресс и DBS; для чтения достаточно предусмотренного документацией доступа к информации о заказах либо другого разрешённого права.

Эти три идентификатора стоит хранить вместе. Один номер заказа не описывает всю историю возвратов и не заменяет номер конкретного обращения. Проверка фотографий возвращаемого товара дополняет заявление, но не превращает снимок упаковки в документ с текстом обращения покупателя.

Как не сохранить ошибку вместо PDF

Успешный ответ метода содержит бинарный файл. Ошибки API передаются в другом формате. Поэтому интеграции недостаточно присвоить любому полученному содержимому расширение .pdf: документ с таким названием может оказаться коротким сообщением о неверном идентификаторе или недостаточном доступе.

Рекомендуемый контроль включает HTTP-статус, тип содержимого и попытку открыть файл PDF. Неудачное скачивание отмечайте отдельным состоянием «документ не получен», а не «заявление отсутствует». Это разные выводы: первый описывает технический результат, второй утверждает факт о покупателе и требует оснований.

Как организовать карточку возврата

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

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

Что проверить перед решением

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

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

Это практическое руководство по документации, проверенной 21 октября 2026 года. Дата проверки не является датой запуска функции; конкретное решение по обращению принимают на основании его обстоятельств и действующих правил площадки.