Ваша интеграция отправляет обновление цены или остатков, получает ACCEPTED и помечает задачу выполненной. Затем продавец сообщает, что товар по-прежнему нельзя купить. Пропущенный шаг — сверить отправку с последующим наблюдением за листингом.
Amazon различает принятие в обработку и проблемы, возникшие позже при обработке. Ответ на запись не может сообщить о проблемах, появившихся после неё; последующее чтение через getListingsItem может их показать. Сохраняйте квитанцию, но не используйте её как доказательство того, что целевое живое состояние достигнуто. Обзор Listings Items от Amazon описывает эту границу.
Этот ранбук предназначен для авторизованной интеграции, которая проверяет собственный отдельный или продаваемый дочерний SKU своего продавца в одном маркетплейсе Amazon. Пример с остатками использует фулфилмент силами продавца и канал DEFAULT. Он не сверяет запасы FBA, офферы конкурентов или Featured Offer. Родительский товар вариации намеренно недоступен для покупки, поэтому исключайте его из оповещения, которое ожидает покупаемый товар. Руководство Amazon по рабочим процессам документирует это исключение.
Храните четыре записи вместо одного флага успеха
Используйте предлагаемую структуру записей, чтобы каждый вывод можно было проверить:
| Запись | Что сохранять | Что она может установить |
|---|---|---|
| Целевое бизнес-состояние | Продавец, SKU, маркетплейс, внутренняя ревизия, целевая цена/валюта, намерение по остаткам и статус продажи | Что именно ваш бизнес хотел изменить |
| Квитанция отправки | Время запроса, операция, статус ответа, идентификатор отправки и возвращённые проблемы | Приняла ли Amazon изначально эту отправку |
| Вклад продавца | Запрошенные данные attributes из последующего чтения с временем их сбора | Последние переданные атрибуты, которые вернула Amazon |
| Наблюдаемое состояние листинга | Сводка в нужном скоупе, офферы, доступность фулфилмента и проблемы из того же чтения | Что эти возвращённые наборы данных сообщают о листинге |
Это отдельные записи, а не атомарная транзакция. Сохраняйте ответ и время сбора, чтобы тот, кто будет разбирать случай позже, мог отличить сравнение полей от предположения о порядке обработки.
Amazon говорит, что attributes представляют последние данные, переданные продавцом, тогда как разделы вроде fulfillmentAvailability представляют живые данные листинга. Эти количества могут законно расходиться после продажи. Сравнение отправленных остатков с живыми так, будто они всегда обязаны совпадать, создаёт ложный сигнал к исправлению. Замечания по Listings Items приводят именно этот пример.
Запрашивайте те наборы данных, которые собираетесь проверять
getListingsItem по умолчанию возвращает summaries. Успешный запрос без offers не проверил живую цену оффера. Явно выбирайте наборы данных, нужные для этого расследования. Справочник по операции перечисляет параметры и значения по умолчанию.
Это форма запроса для уже существующего авторизованного клиента SP-API, а не полная аутентифицированная команда:
GET /listings/2021-08-01/items/{sellerId}/{sku}
marketplaceIds={marketplaceId}
includedData=summaries,attributes,issues,offers,fulfillmentAvailabilityИспользуйте региональную конечную точку и контекст авторизованного продавца, уже настроенные в вашем клиенте, кодируйте SKU как компонент пути и передавайте последние две строки как параметры запроса. Мы намеренно проверяем один маркетплейс за одно расследование, чтобы упростить атрибуцию.
Сопоставьте возвращённый SKU и сводку целевого маркетплейса. Для проверки цены выберите оффер для этого маркетплейса, целевой тип оффера B2C или B2B, применимую аудиторию, если она есть, и ожидаемую валюту. Если целевой оффер нельзя выбрать однозначно, оставьте проверку цены неразрешённой. Сравнивайте денежные суммы как десятичные числа, а не как приближения с плавающей точкой.
Для этого примера с фулфилментом силами продавца проверяйте канал фулфилмента DEFAULT, который Amazon определяет как стандартный фулфилмент продавца в своём руководстве по фулфилменту. Не подставляйте другой канал и не считайте отсутствующее количество нулём. Официальная модель ответа делает несколько наборов данных необязательными и не требует наличия количества по фулфилменту. Отсутствующие данные — отдельный результат в этом ранбуке.
Превращайте каждое наблюдение в конкретное следующее действие
Следующая матрица — операционная политика, выведенная из семантики этих ответов. Это не гарантия завершения от Amazon.
| Наблюдение | Допустимый вывод | Следующее действие |
|---|---|---|
Отправка в статусе ACCEPTED; последующего чтения нет | Принято, живой результат не проверен | Поставить в очередь чтение в нужном скоупе; сохранить квитанцию |
| Чтение завершилось ошибкой авторизации, троттлинга или сервиса | Текущее состояние листинга неизвестно | Устранить сбой чтения; не смешивать его со статусом листинга |
| В успешном ответе нет нужного набора данных или подходящего оффера | Эта проверка в состоянии «неизвестно» | Проверить запрошенные наборы данных и скоуп; не заполнять отсутствующие значения нулём или false |
В валидной сводке цели нет BUYABLE для SKU, который должен продаваться | Возвращённый статус — «не покупаемый» | Изучить запрошенные проблемы и доступность фулфилмента; проверить намеренное закрытие и намерение по остаткам |
| Набор данных issues пуст | В этом наборе данных проблемы не сообщаются | Проверить возможность покупки отдельно; не выводить её из пустого списка |
| Для целевого листинга сообщены проблемы | Эти сообщённые проблемы требуют диагностики | Изучить код, серьёзность, затронутые атрибуты и сведения о маркетплейсе/принудительных мерах, где они даны; разобрать каждую применимую проблему, проверяя возможность покупки отдельно |
| Возвращённый оффер совпадает с целевой ценой и валютой | Этот наблюдаемый оффер совпадает | Зафиксировать совпадение; остатки и возможность покупки оценивать отдельно |
| Однозначно выбранный оффер имеет ожидаемую валюту, но другую цену | Наблюдаемое расхождение цены; требует внимания | Сохранить ожидаемое/наблюдаемое значения, проверить последнюю бизнес-ревизию и другие записи, затем продолжить ограниченную сверку или эскалировать; не переотправлять вслепую |
| Переданные остатки отличаются от живых | Возвращены два разных вида количества | Свериться с текущим источником истины по остаткам и промежуточными изменениями до любой записи |
BUYABLE и DISCOVERABLE описывают разные состояния. Валидный массив статусов без BUYABLE — это не то же самое, что отсутствующая сводка или неудачное чтение. Amazon также говорит, что отсутствие определённых проблем может сосуществовать с другими проблемами листинга. Определения уведомлений о статусе и проблемах описывают эти различия; руководство по получению данных связывает диагностику «не покупаемого» состояния с проблемами и остатками.
Обрабатывайте сбои HTTP на уровне запросов. Справочник различает ошибки авторизации 403, троттлинг 429 и ошибки сервиса 500/503. 404 требует расследования листинга и скоупа запроса; он не означает подтверждённого нулевого остатка. Используйте ограниченные повторы чтения там, где это уместно, в рамках текущего плана использования API, не превращая каждое неудачное чтение в новую запись листинга. Ответы getListingsItem дают категории ошибок.
Разберите расхождение количества, прежде чем его исправлять
Рассмотрим полностью иллюстративную трассу, а не живой тест на аккаунте продавца. Целевое обновление — цена B2C 24,90 USD и пять единиц с фулфилментом силами продавца для одного продаваемого SKU. Отправка принята. Более позднее чтение в правильном скоупе сообщает:
| Поле | Иллюстративное наблюдение | Интерпретация |
|---|---|---|
Отправленные остатки в attributes | 5 | Возвращён последний переданный вклад |
Живое количество в DEFAULT | 4 | В этом канале доступными сообщены четыре единицы |
| Выбранный оффер | 24,90 USD | Наблюдаемая цена совпадает с целевой суммой и валютой |
| Статус в сводке | BUYABLE, DISCOVERABLE | Для этого листинга сообщены оба состояния |
| Запрошенные проблемы | Пустой массив | Проблем там не сообщено |
Разница в остатках сама по себе не доказывает, что обновление не сработало. Продажа — одно из возможных объяснений, но этот ответ не устанавливает причину. Сверьтесь с системой учёта остатков и промежуточными заказами или записями, прежде чем решать, нужна ли коррекция. Слепое восстановление пяти единиц может отменить законное изменение остатков.
Обратный короткий путь тоже не работает: совпадающая цена не доказывает, что именно эта отправка привела к наблюдаемому значению. Ту же сумму мог передать другой источник записи. Зафиксируйте наблюдаемое совпадение, сохраните внутреннюю ревизию и квитанцию, а причинно-следственную связь не утверждайте.
Если бы это чтение запросило только summaries, возможность покупки была бы видна, а проверки цены и количества остались бы в состоянии «неизвестно». Сохраняйте этот частичный результат, вместо того чтобы объявлять всю задачу успешной.
Ограничьте расследование и сохраняйте пользу запоздалых уведомлений
Ведите запись сверки на каждую комбинацию продавца, SKU, маркетплейса и внутренней ревизии. Дайте каждой обязательной проверке собственное состояние: ожидает, наблюдаемое совпадение, требует внимания или неизвестно. Более новая бизнес-ревизия должна заменять старую цель, а не перезаписываться повтором той старой задачи.
Выберите расписание повторов, максимальное число попыток и срок расследования, соответствующие вашему риску по остаткам и выделенной квоте API. Это ваши операционные решения; этот ранбук не даёт универсальной задержки, после которой принятое обновление обязано быть в продаже. По истечении срока эскалируйте неразрешённые проверки вместе с сохранённой квитанцией, скоупом, временем сбора и релевантными полями ответа.
Используйте применимые уведомления о статусе или проблемах, чтобы запланировать ещё одно чтение в нужном скоупе, и используйте ограниченный проход сверки для задач, которые всё ещё ожидают. Сохраняйте идентификатор и время уведомления для диагностики. Запоздалое уведомление должно запускать расследование, но не заменять более новое наблюдение только потому, что пришло последним. FAQ по Listings APIs от Amazon признаёт, что уведомления могут отставать от прямых чтений.
lastUpdatedDate в сводке — это отметка времени обновления листинга. Модель не определяет её как отдельную отметку актуальности для каждого поля цены или остатков. Не считайте её доказательством того, что все возвращённые разделы описывают одно атомарное состояние или что ваша отправка полностью применена.
Отделяйте диагностику транспорта от решений по листингу
Смена прокси не может устранить проблему каталога только потому, что запрос теперь завершается. Если запрос падает до получения полезного ответа, диагностируйте соединение по руководству по таймаутам прокси. Когда приходит валидный ответ о листинге, используйте его поля в нужном скоупе и ваше бизнес-намерение, чтобы решить, что делать дальше.
Для отдельного процесса сбора публичных страниц статья о том, содержит ли HTTP 200 от Amazon нужную страницу, отвечает на другой вопрос. Этот процесс сверки для продавца использует авторизованные данные SP-API и не выводит состояние листинга из собранной витрины.
Эта статья и её матрица решений подготовлены с помощью ИИ на основе первичной документации Amazon, полученной 12 сентября 2026 года, а затем независимо проверены. Пример иллюстративный; ни один аккаунт продавца не запрашивался и ни один листинг не изменялся. Матрица — предлагаемый операционный метод, а не измеренный результат восстановления.
Присоединяйтесь к списку ожидания ipvolt, чтобы получить одно уведомление, когда откроется доступ к прокси. Доступ пока не открыт. Одно письмо, когда доступ откроется. Больше ничего.