При переходе интеграции на Shopify GraphQL Admin API 2026-10 нужно проверить запросы, которые забирают заказы после времени последней обработанной записи. Оператор «больше» для временной метки без долей секунды теперь исключает всю указанную секунду. Разъяснение опубликовано 19 октября; этот практический разбор подготовлен по документации, проверенной 27 октября 2026 года.

Почему одинаковое время не означает один заказ

В ответе API время может отображаться с точностью до секунды, хотя внутри ресурс хранит более точное значение. Раньше запрос с исключающей нижней границей мог вернуть запись из более поздней части той же секунды. В версии 2026-10 такая запись уже не попадает под условие с оператором > и меткой без дробной части.

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

Что найти в настройках обмена

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

Shopify рекомендует для такого сценария включающую границу >= и удаление повторов по id, если требуется не пропускать записи внутри последней секунды. Это не означает, что все операторы времени изменились: в анонсе отдельно исключены другие сравнения, даты без времени и значения с дробной частью секунды.

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

Как проверить повторный запуск

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

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

Как отличить выгрузку от потока событий

Если одновременно используются уведомления, анализируйте оба пути отдельно. Изменение событий carts/update касается корзины и другого условия отправки. Оно не объясняет пропажу заказа из запроса по времени. Аналогично Next Gen Events не отменяет проверки сохранённой границы в периодической выгрузке.

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