В этом документе перечислены квоты, применяемые к API для продавцов.
API для продавцов использует квоты, чтобы обеспечить стабильную и справедливую среду для всех пользователей. Квоты предотвращают чрезмерную нагрузку на систему со стороны одного пользователя API, обеспечивая высокую производительность. Понимание этих квот является ключом к управлению данными о ваших товарах и масштабированию вашего бизнеса в Google.
Общие понятия
Управление квотами API для продавцов осуществляется посредством групп квот.
Методы API сопоставляются с группами квот. Структура этого сопоставления может варьироваться:
- Один метод на группу: Некоторые группы квот применяются к одному методу API. Например, метод
accounts.dataSources.list, отображающий источники данных, имеет свою собственную выделенную группу квот. - Несколько методов в группе (объединение): Часто связанные методы объединяются в одну группу с квотами. Все методы в этой группе имеют одинаковые суточные и поминутные лимиты. Типичные примеры:
- Группировка всех операций чтения для связанных методов и ресурсов, таких как
merchant-accounts-read-methods. - Группировка всех операций записи для связанных методов и ресурсов, таких как
merchant-accounts-write-methods.
- Группировка всех операций чтения для связанных методов и ресурсов, таких как
Каждый вызов метода учитывается один раз, независимо от его типа. Запрос list из 250 элементов учитывается только один раз, а не как 250 запросов get .
Встроенная пакетная обработка HTTP-запросов не влияет на квоту. Каждый отдельный запрос в пакете запросов учитывается как один запрос в рамках квоты. Например, пакетный запрос, содержащий 500 запросов insert , будет учитываться как 500 отдельных запросов на вставку с использованием метода insert .
Исключение для пакетной обработки данных по выделенным регионам: специализированные методы пакетной обработки данных по регионам ( batchCreate , batchUpdate , batchDelete ) учитываются как один вызов API в рамках группы квот merchant_regions , независимо от количества операций с регионами, содержащихся в полезной нагрузке.
Для эффективного управления интеграцией следует проверить конкретную группу квот, связанную с каждым методом API, который вы планируете использовать. Эти сведения можно найти в списке методов квот. Дополнительную информацию см. в разделе «Мониторинг и видимость» .
Обновить политику
API для продавцов применяет следующие правила в отношении обновлений:
- По умолчанию вы можете обновлять свои продукты до двух раз в день. Чтобы соблюсти лимит поминутных обновлений, следует равномерно распределить запросы в течение дня.
- По умолчанию вы можете обновлять свои дочерние учетные записи не более двух раз в день. Ваша ежедневная квота на обновление дочерних учетных записей — это совокупный лимит, основанный на общем количестве разрешенных дочерних учетных записей.
- По умолчанию вы можете вызывать методы источника данных для ваших дочерних учетных записей, такие как
listилиcreateне более двух раз в день для каждой дочерней учетной записи.
тарифные квоты
Каждая группа квот имеет два типа ограничений (и ежедневное использование):
- Дневной лимит (
quotaLimit): максимальное количество запросов, разрешенных в день. Дневные лимиты квот обнуляются в 12:00 по UTC . - Поминутный лимит (
quotaMinuteLimit): максимальное количество запросов, разрешенных в минуту, регулирующее скорость запросов. Поминутные лимиты используют скользящее окно, период действия которого начинается с момента первого вызова API для данного метода и ресурса. Например, если вы совершаете вызов в 10:01:30 , поминутное окно квоты для этого метода будет действовать до 10:02:30 . - Ежедневное использование (
quotaUsage): количество запросов, которые уже были выполнены и учтены в рамках дневного лимита на текущий день. Если это поле отсутствует, значит, квота для данной группы еще не использована.
Три описанных ранее поля ( quotaLimit , quotaMinuteLimit и quotaUsage ) можно найти в ответе метода quotas.list .
Конкретные суточные и поминутные лимиты значительно различаются в зависимости от группы квот. Для операций с большим ожидаемым объемом или меньшими системными затратами, таких как чтение данных о продуктах, обычно устанавливаются более высокие лимиты. И наоборот, для более интенсивных или конфиденциальных операций, таких как изменение данных в учетных записях, могут быть установлены более низкие лимиты.
Распределение квот и иерархия
В этом разделе объясняется, от чьего имени API продавца отслеживает и применяет использование квот:
Как правило, плата за использование квоты взимается в зависимости от пользователя, который отправляет запрос к API.
- Автономные учетные записи: Для автономных учетных записей, выполняющих аутентификацию вызова API, этот запрос учитывается в рамках квоты данной учетной записи.
- Пример: Магазин обуви A (идентификатор учетной записи: 12345) проходит аутентификацию, используя свою собственную учетную запись службы, для вызова функции
products.insert, нацеленной на его собственную учетную запись (accounts/12345). Квота расходуется из пула квот магазина обуви A.
- Пример: Магазин обуви A (идентификатор учетной записи: 12345) проходит аутентификацию, используя свою собственную учетную запись службы, для вызова функции
- Расширенные учетные записи: Аутентификация в качестве расширенной учетной записи расходует квоту из пула расширенной учетной записи, даже если она нацелена на суб-учетную запись .
- Пример: Учетная запись управления розничной торговлей агентства (расширенный идентификатор учетной записи: 12345) управляет суб-аккаунтом «Магазин одежды B» (идентификатор учетной записи: 11111). Агентство проходит аутентификацию, используя свои собственные учетные данные, и вызывает метод
products.insert, нацеленный на магазин одежды B (accounts/11111). Квота расходуется из пула родительского агентства (расширенный идентификатор учетной записи: 12345), а не из пула суб-аккаунта.
- Пример: Учетная запись управления розничной торговлей агентства (расширенный идентификатор учетной записи: 12345) управляет суб-аккаунтом «Магазин одежды B» (идентификатор учетной записи: 11111). Агентство проходит аутентификацию, используя свои собственные учетные данные, и вызывает метод
- Дополнительные учетные записи: При аутентификации вызовов API с использованием учетных данных дополнительной учетной записи квота списывается с индивидуального пула этой дополнительной учетной записи. Это работает так же, как и с автономной учетной записью, даже если она управляется родительской расширенной учетной записью.
- Пример: Используя ту же конфигурацию, что и раньше, если магазин одежды B (идентификатор учетной записи: 11111) проходит аутентификацию с использованием учетных данных, специально настроенных для его суб-аккаунта, чтобы вызвать
products.insert, нацеленный на его собственную учетную запись (accounts/11111), квота расходуется из индивидуального пула квот магазина одежды B , оставляя пул родительского агентства нетронутым.
- Пример: Используя ту же конфигурацию, что и раньше, если магазин одежды B (идентификатор учетной записи: 11111) проходит аутентификацию с использованием учетных данных, специально настроенных для его суб-аккаунта, чтобы вызвать
Исключения из общих правил
Существует несколько конкретных исключений, которые применяются к общим правилам распределения квот:
- Accounts.list : Квота для этого метода списывается с учетной записи аутентифицированного пользователя или сервиса, выполняющего вызов, а не с идентификатора учетной записи Merchant Center. Использование квоты не будет отображаться на стандартной странице диагностики API Merchant Center . Если у вас расширенная учетная запись, мы рекомендуем использовать метод
accounts.listSubaccounts, который учитывается в вашей квоте для расширенных учетных записей. - Методы разрешения проблем : Эти методы всегда учитываются в квоте для учетной записи, для которой запрашиваются проблемы, даже если запрос аутентифицируется другой учетной записью.
Иерархия распределения
Сервисы сравнения цен (CSS): CSS — это веб-сайты, которые агрегируют предложения товаров и направляют пользователей на веб-сайты розничных продавцов для совершения покупок. При выполнении API-запросов применяются квоты к конкретной группе CSS, домену CSS, учетной записи или суб-учетной записи, к которой вы обращаетесь для аутентификации.
Примеры:
- Группа компаний, использующих CSS-технологии, под названием Europe Shopping Group (идентификатор учетной записи: 10001) хочет получить список связанных с ней доменов CSS. Для выполнения этого API-запроса, используя собственные учетные данные, квота расходуется непосредственно из пула квот Europe Shopping Group .
- Домен CSS TopDeals CSS (идентификатор учетной записи: 20002) проходит аутентификацию для вызова метода, нацеленного на одну из связанных с ним учетных записей продавцов (
accounts/30003), для присвоения метки. Квота расходуется из пула квот TopDeals CSS , а не из пула квот учетной записи продавца.
Торговые площадки: Торговые площадки — это онлайн-платформы, на которых размещается множество отдельных продавцов. Они функционируют как специальные расширенные учетные записи, позволяющие создавать отдельные субаккаунты для каждого из ваших продавцов.
На следующей диаграмме показана иерархия групп CSS, CSS, торговых площадок, расширенных учетных записей, автономных учетных записей и суб-учетных записей.

Автоматическая корректировка квоты
API для продавцов имеет автоматическую систему управления квотами для определенных сервисов, которая корректирует лимиты квот для растущих продавцов в зависимости от вашего использования, предложения и размера аккаунта. API для продавцов пересчитывает эти квоты ежедневно.
В автоматическую корректировку квот включаются следующие группы квот:
Продукция и услуги
- Все группы квот методов, относящиеся к
productsи ресурсамproductInputs. - Ежедневная квота звонков обычно устанавливается в 2 раза больше, чем квота предложений, имеющаяся у продавца. Это предполагает, что продавцу может потребоваться обновлять каждый из своих товаров до двух раз в день.
- Отдельные продукты можно обновлять более двух раз, но общее количество ежедневных вызовов API не должно превышать совокупную суточную квоту вызовов.
Бухгалтерские услуги
- Все группы квот методов, относящиеся к различным детализированным ресурсам, связанным с учетной записью, в API продавца.
- Ежедневная квота на звонки устанавливается на максимальное количество субсчетов, разрешенных для данного счета. Это позволяет совершать до двух звонков на прочтение на каждый субсчет в день.
Источники данных и сервисы
- Все группы квот методов, связанных с ресурсами, относящимися к источнику данных в API продавца, такие как
listилиcreate, которые расширенный аккаунт выполняет для своих субаккаунтов. - Ежедневная квота на звонки обычно устанавливается в 2 раза больше количества субсчетов, которые есть у расширенного аккаунта. Это предполагает, что продавец может обновлять источники данных каждого из своих субсчетов до двух раз в день.
Автоматическая корректировка квот доступна только для описанных ранее сервисов. Для других сервисов установлена квота по умолчанию, и любое её увеличение необходимо запрашивать вручную. Дополнительную информацию см. в разделе «Процесс увеличения квот» .
Что происходит, когда квоты превышены?
После превышения квоты в ответах API и на странице диагностики в вашем аккаунте Merchant Center появятся ошибки:
- За минуту:
quota/request_rate_too_high
{
"error": {
"code": 429,
"message": "Quota per minute exceeded. Please distribute your requests over a longer time period. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
"status": "RESOURCE_EXHAUSTED",
"details": [
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "quotaExceeded",
"domain": "merchantapi.googleapis.com",
"metadata": {
"HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
"REASON": "QUOTA_REQUEST_RATE_TOO_HIGH"
}
}
]
}
}
- В день:
quota/daily_limit_exceeded
{
"error": {
"code": 429,
"message": "Daily request quota exceeded. Please reduce number of requests. For more information check https://developers.google.com/merchant/api/guides/quotas-limits",
"status": "RESOURCE_EXHAUSTED",
"details": [
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "quotaExceeded",
"domain": "merchantapi.googleapis.com",
"metadata": {
"HELP_CENTER_LINK": "https://developers.google.com/merchant/api/guides/quotas-limits",
"REASON": "QUOTA_TOO_MANY_REQUESTS"
}
}
]
}
}
Следующие ошибки связаны с ограничениями Merchant Center и не имеют отношения к квотам Merchant API. Вы можете попробовать запросить дополнительную квоту на товары, фиды или субсчета :
-
too_many_items: Превышена квота продавца -
too_many_subaccounts: Достигнуто максимальное количество субсчетов
Мониторинг и прозрачность
Чтобы проверить текущие квоты на звонки и объем использования для учетной записи, вызовите quotas.list , указав имя учетной записи.
POST https://merchantapi.googleapis.com/quota/v1/accounts/{ACCOUNT_ID}/quotas
Content-Type: application/json
Authorization: Bearer {ACCESS_TOKEN}
Замените следующее:
-
ACCOUNT_ID: ваш идентификатор Merchant Center -
ACCESS_TOKEN: токен авторизации для выполнения вызова API.
В случае успешного запроса API возвращает список ресурсов quotaGroups , содержащий name ресурса группы квот, различные квоты и методы, к которым применяется квота группы.
{
"quotaGroups": [
{
"name": "accounts/{ACCOUNT_ID}/quotas/merchant-quota-listquotagroups",
"quotaUsage": "2",
"quotaLimit": "1000",
"methodDetails": [
{
"method": "quotaservice.listquotagroups",
"version": "v1",
"subapi": "quota",
"path": "quota/v1/quotaservice.listquotagroups"
}
],
"quotaMinuteLimit": "10"
},
{
"name": "accounts/{ACCOUNT_ID}/quotas/merchant-commission-group-list",
"quotaLimit": "10000",
"methodDetails": [
{
"method": "commissiongroupservice.listcommissiongroups",
"version": "v1",
"subapi": "youtube",
"path": "youtube/v1/commissiongroupservice.listcommissiongroups"
}
],
"quotaMinuteLimit": "60"
},
{
"name": "accounts/{ACCOUNT_ID}/quotas/merchant-merchantreviews-list",
"quotaLimit": "20000000",
"methodDetails": [
{
"method": "merchantreviewsservice.listmerchantreviews",
"version": "v1",
"subapi": "reviews",
"path": "reviews/v1/merchantreviewsservice.listmerchantreviews"
}
],
"quotaMinuteLimit": "60000"
}
]
}
процесс увеличения квоты
Чтобы запросить дополнительную квоту, откройте форму «Связаться со службой поддержки» , выберите «Запрос на увеличение квоты» в обязательном поле «В чем проблема/вопрос» и заполните все обязательные поля, включая идентификатор вашего Merchant Center, целевые методы и обоснование целесообразности.
- Для ресурсов с автоматическими квотами (
products,accountsиdatasourcesдля расширенных учетных записей): вы можете запросить только временное увеличение квоты для особых сценариев, таких как выход на новый рынок или в периоды пиковой активности покупателей. Мы не принимаем запросы на постоянное увеличение квоты для таких типов ресурсов. - Для всех остальных ресурсов, для которых не установлены автоматические квоты: при необходимости запрашивайте увеличение квоты.
Мы рекомендуем периодически проверять ваши квоты, чтобы убедиться в их достаточности для вашей реализации, и следить за тем, как ваша квота автоматически корректируется. Используйте метод quotas.list , чтобы увидеть текущий суточный лимит квоты, лимит минут и текущее суточное использование для каждой группы методов API.
Передовые методы
Внедрение этих передовых методов помогает обеспечить бесперебойную работу интеграции, избежать неожиданных ошибок с квотами и эффективно использовать ресурсы Merchant Center.
Оптимизация распределения запросов
- Распределяйте запросы равномерно: избегайте отправки больших объемов запросов. Распределяйте ежедневные вызовы API равномерно в течение дня, чтобы оставаться в пределах лимитов квоты в минуту (
quotaMinuteLimit). - Проактивное регулирование: Внедрите в ваше приложение ограничение скорости запросов на стороне клиента (регулирование скорости). Не полагайтесь исключительно на серверы Google для отклонения избыточного трафика. Контролируйте скорость запросов на источнике.
Корректная обработка ошибок
- Обработка HTTP-ошибки 429: Ваше приложение должно быть готово к обработке ошибок 429 Too Many Requests (
quota/request_rate_too_high). - Экспоненциальная задержка с джиттером: При повторной попытке обработки неудачных запросов (особенно после ошибки 429) используйте экспоненциальную задержку (увеличение времени ожидания) и добавьте «джиттер» (случайную задержку). Джиттер предотвращает «шторм повторных попыток», когда несколько экземпляров клиента одновременно пытаются выполнить запрос, снова перегружая сервер.
- Учитывайте подсказки о повторных попытках: если ответ API содержит сведения о повторных попытках или заголовки, используйте их для определения момента возобновления вызовов.
Сведите к минимуму избыточные звонки.
- Предотвращение устаревших вызовов (404 NOT_FOUND): Избегайте запросов или удаления ресурсов, которые больше не существуют. Даже неудачные вызовы расходуют квоту API. Отслеживайте ошибки
NOT_FOUNDв диагностике API Merchant Center, чтобы обнаружить устаревшее отслеживание состояния или ненужный опрос. - Проверка перед обновлением: Перед отправкой запроса на обновление убедитесь, что данные действительно изменились. Избегайте отправки обновлений, в которых записываются одни и те же значения.
- Используйте кэширование: кэшируйте ответы на запросы чтения (например, сведения о продукте, настройки) локально, когда это необходимо, чтобы избежать повторных вызовов методов
getилиlistдля неизмененных данных.
Навигация по иерархии квот и исключениям
- Расширенные учетные записи и суб-учетные записи: Если у вас расширенная учетная запись, выполните аутентификацию на уровне расширенной учетной записи, чтобы звонки учитывались в общем пуле расширенной учетной записи.
- Используйте
listSubaccounts: Для расширенных учетных записей используйтеaccounts.listSubaccountsвместоaccounts.list. Квотаaccounts.listвзимается с вызывающего пользователя (а не с идентификатора MC) и не отображается в стандартной диагностике.listSubaccountsучитывается в вашей квоте MCA.