API, или программный интерфейс приложения, — это заданный контракт, который позволяет двум отдельным программам обмениваться данными и инициировать действия друг в друге без ручного управления со стороны человека. В управлении фидами именно API позволяют системе учёта товаров продавца, платформе управления фидами и торговому каналу напрямую взаимодействовать друг с другом — автоматически передавать изменения цен, обновления остатков и новые товарные предложения в обе стороны, а не ждать, пока кто-то загрузит файл по расписанию. Если традиционный процесс работы с фидом может обновляться раз в день через FTP, то фид, подключённый через API, может отразить отсутствие товара или снижение цены в течение нескольких минут.
Почему это важно для управления фидами
Скорость и точность приобретают всё большее значение по мере роста каталога. Ритейлер, продающий десять тысяч SKU в пяти каналах, не может вручную загружать таблицу заново при каждом изменении цены или окончании товара; API позволяет автоматически распространять такое обновление, благодаря чему реклама не показывается для отсутствующих товаров или товаров с неверной ценой. API также делают управление фидами расширяемым: вместо того чтобы ограничиваться полями, которые поддерживает шаблон загрузки файлов платформы, инструмент для работы с фидами может напрямую обращаться к API канала, чтобы передавать более полные данные, получать причины отклонения или выгружать показатели эффективности в ту же систему, которая управляет каталогом. Этот двусторонний обмен лежит и в основе триггеров реального времени, таких как вебхук, когда внешнее событие — новый заказ, изменение цены в ERP — вызывает конечную точку API в момент, когда оно происходит, а не с фиксированным интервалом. По мере того как покупки всё больше переходят к ИИ-агентам и диалоговой коммерции, чистый и хорошо задокументированный уровень API за каталогом становится базовым требованием, а не приятным дополнением; об этом сдвиге рассказывается в нашем руководстве о готовности фидов к агентной коммерции.
Как это работает
Большинство API, связанных с фидами, построены по принципу REST: клиент отправляет HTTP-запрос на определённый URL конечной точки, добавляет ключ API или токен OAuth для аутентификации и получает структурированный ответ, обычно в формате JSON. Например, запрос на обновление цены товара может быть вызовом PATCH к конечной точке вида /products/{id}, при этом новая цена передаётся в теле запроса, а токен авторизации — в HTTP-заголовках. API точно определяет, какие конечные точки существуют, какие данные ожидает каждая из них, что она возвращает и что означают коды ошибок, — именно этот задокументированный контракт и называется «программным интерфейсом приложения». Лимиты запросов, версионирование и области действия аутентификации являются частью того же контракта, и платформа фидов должна их соблюдать, чтобы канал, с которым она синхронизируется, не ограничил и не заблокировал её.
Пример
<item>
<g:id>SKU-88213</g:id>
<title>Stainless Steel Pour-Over Coffee Dripper</title>
<g:price>34.00 USD</g:price>
<g:availability>in stock</g:availability>
<custom_label_0>api_synced</custom_label_0>
<last_synced_via>merchant-api-v3</last_synced_via>
<last_updated>2026-08-15T09:41:00Z</last_updated>
</item>
Поля last_synced_via и last_updated выше не являются стандартными атрибутами Google или Meta, но многие платформы фидов отслеживают их внутри системы, чтобы показывать, какие товары были переданы через прямое подключение по API, а какие — через пакетную загрузку файла, и насколько свежи эти данные.
Связанные понятия
API — это транспортный уровень, благодаря которому возможны и другие концепции управления фидами: вебхук по сути является вызовом API в обратном направлении, инициируемым событием, а не запросом; данные, передаваемые в обоих случаях, обычно структурированы в формате JSON; и каждый запрос содержит HTTP-заголовки, которые аутентифицируют вызов и описывают передаваемые данные. Понимание API лежит в основе понимания того, как современные платформы фидов синхронизируются с каналами почти в реальном времени, а не по фиксированному ежедневному расписанию.
















