Google Updates Merchant API Quotas Guide With New Resource Representation Limits on January 23, 2026
Google revised its Merchant API quotas and limits documentation on January 23, 2026, publishing a clearer set of “resource representation” caps that affect how developers submit and manage shipping settings in Google’s Merchant Center, the company’s product listing and account management service used for Shopping ads and free listings. According to Google’s January 23 documentation update, the field-level limits match the constraints merchants encounter in the Merchant Center interface. The change matters most for US retailers, agencies, and ecommerce platforms that automate catalog and delivery configuration at scale through the API.
What changed in the Merchant API quotas documentation?
Google’s guide now distinguishes two layers of constraints that can stop an integration in different ways. One layer covers method quotas that restrict request volume, including per-minute and per-day limits that return quota errors such as “quota/request_rate_too_high” and “quota/daily_limit_exceeded.” The other layer covers “resource representation” limits, which cap the size and complexity of specific fields inside a single API resource payload.
The documentation also describes service-specific quota behavior. Google states that automatic quota adjustments apply to the Merchant API’s products and accounts services, while other services may require a support request when an implementation needs higher thresholds. The same guide describes update-frequency restrictions under its update policy, including a limit of two product updates per day and one sub-account update per day.
Which resource representation limits affect shipping settings?
The newly emphasized caps center on the shipping settings resource, which many merchants use to encode delivery rules across regions, weight breaks, and price tiers. Google’s guide lists limits on array fields and string lengths that can constrain complex delivery models, especially when a merchant tries to encode many shipping programs inside one account configuration.
Google’s published ceilings include:
- 20 shipping services per country
- 20 shipping groups per shipping service
- 30 labels per shipping group
- 100 subtables per shipping group
- 150 maximum rows or columns in a single rate table
- 100-character maximum length for a shipping label
Google also explains that rate-table size limits ripple through nested arrays used for headers and cells, which can inflate payload size when a configuration spans many tiers or destinations. For developers, the practical risk is a shipping setup that works in internal tooling but fails once serialized into the API object because a nested array crosses a hard ceiling.
How do these API limits relate to Merchant Center account quotas?
Merchant Center enforces separate caps on catalog size and account structure, and those caps can intersect with API throughput and representation limits. Google describes quotas that apply to products, sub-accounts under multi-client accounts, data sources, and API call volume, and it frames the limits as stability and fair-use safeguards. The details appear in the Merchant Center help documentation, which lays out default limits and enforcement behavior across common account types.
The help guidance gives examples that many US retailers see in day-to-day operations. It lists a 150,000 default product quota per scope for standalone accounts and standard sub-accounts, alongside higher defaults for certain platform and marketplace multi-client accounts. The same guidance says enforcement can apply at both the sub-account and parent multi-client-account levels, which can prevent new items from processing even when a sub-account still has room under its own cap.
In practice, large merchants and service providers often face a combined constraint set: catalog quotas determine how much data can exist in the account, method quotas govern how quickly systems can change that data, and representation limits define how complex a single shipping settings object can become before it is rejected.
What timelines matter for US integrations?
The quota and representation limits arrive while Google pushes developers toward its stable Merchant API release. Per Google’s migration guide, Merchant API v1beta is scheduled to be discontinued and shut down on February 28, 2026, and Google directs integrators to migrate to v1. That schedule matters for teams that built on earlier versions without guardrails around shipping configuration size, update cadence, or version-specific changes that require code edits.
For developers, two failure modes stand out: shipping settings that exceed representation caps, and bursts of updates that trigger per-minute or per-day quota errors. For merchants, the operational signal is usually a stalled change, such as a delivery update that stops applying to listings or a catalog refresh that fails to process after a quota threshold is reached. Google’s documentation ties these outcomes to quota enforcement and to hard limits on how large certain shipping settings objects can be.
Google’s January 23 documentation revision does not itself change listing eligibility, but it makes the technical ceilings explicit for companies that automate catalog and shipping management at US scale.
Ajay Mistry
Ajay Mistry works in digital marketing strategy, AI-driven optimization, and Google advertising, with experience across Google Ads and Merchant Center. He focuses on improving visibility, account health, and conversions by aligning content, data, and campaigns with platform guidelines. He writes practical guides on advertising performance, compliance, and sustainable growth.