Content API basics for Merchant Center
What the Content API for Shopping is for, the products and inventory endpoints, real-time updates, and when a hosted feed URL is the simpler answer.
The Content API lets software push product data into Merchant Center directly, product by product, in real time, instead of Google fetching a feed file on a schedule. It's the right tool when inventory and prices change constantly and you need updates to land in seconds. For most merchants, a hosted feed URL that Google fetches on a schedule is simpler and covers the same ground.
What the Content API is for
The Content API for Shopping is a programmatic interface for managing Merchant Center data directly. Instead of Google fetching a feed file on a schedule, your software pushes product data to Google, one item at a time, on your timing, in near-real-time.
That's the whole distinction that decides whether you need it:
- Feed file (scheduled fetch): you host a file; Google fetches it every so often; changes land at the next fetch.
- Content API (push): your system calls Google the moment something changes; the update lands in seconds.
Everything else, the attributes, the identifiers, the policies, is the same product data spec either way. The API is a delivery mechanism, not a different data model.
The endpoints you'll actually use
| Endpoint area | What it does | When |
|---|---|---|
| Products | Create, update, retrieve, delete a full product offer | Managing the catalog: new products, full updates, removals |
| Inventory (regional / local) | Update just price and availability on an existing product | Frequent repricing / stock changes without resubmitting the whole offer |
| Product statuses | Read back approval and disapproval state per item | Programmatic Diagnostics, reacting to issues in code |
| Datafeeds / data sources | Register and manage the data sources themselves | Setup and automation of the sources feeding an account |
The split that matters day-to-day is products vs inventory. Rewriting a full product record for every price tick is wasteful; the inventory path updates only the volatile fields (price and availability), which is cheaper and faster, and is the usual pattern for high-frequency changes.
Deep dive When the API earns its complexity, and when it doesn't
The Content API is more capable than a feed and meaningfully more work to run. Deciding honestly:
The API earns its keep when:
- Stock and price move faster than a fetch cycle. If prices reprice through the day or stock sells out in minutes, a once- or twice-daily fetch means listings that are wrong for hours: mismatch disapprovals, or shoppers clicking through to a sold-out product. Per-item push closes that window.
- You're building software, not maintaining a store. Platforms, marketplaces and custom commerce stacks that already have an eventing model can emit an API call on every change naturally. The API fits code; a feed file fits a catalog you export.
- You need programmatic status handling. Reading
productstatusesback lets you react to disapprovals in your own systems rather than a human watching Diagnostics.
A hosted feed URL is the better call when:
- Your catalog changes in batches, not continuously. Most merchants reprice and restock in waves a scheduled fetch handles fine. The API's real-time edge buys nothing if nothing changes between fetches.
- You don't want to own auth, quotas, retries and error handling. The API means OAuth, rate limits, batching, backoff and per-item error handling: a real integration to build and keep alive. A feed URL is a link you paste into a data source. When it breaks, you re-host a file; you don't debug a token refresh.
- You want one output that serves every channel. A hosted feed file is trivially reusable across Google, Bing, Meta and marketplaces. An API integration is Google-specific plumbing.
The honest default for most merchants is a hosted feed URL fetched on a schedule: it delivers the same product data spec, it's simple to run, and it's channel-agnostic. This is exactly where a served feed URL fits: an enrichment layer produces a clean, complete, Google-ready feed and exposes it at a stable URL that Merchant Center fetches on a schedule (see the feed serving URL). You get accurate, enriched data into Merchant Center without owning an API integration, and the same URL feeds every other channel. Reach for the Content API only when real-time, per-item control is a genuine requirement the schedule can't meet, not because it sounds more advanced.
Feed URL vs Content API at a glance
| Hosted feed URL | Content API | |
|---|---|---|
| Direction | Google fetches | Your system pushes |
| Update latency | Next scheduled fetch | Seconds |
| Setup cost | Paste a URL into a data source | Build an OAuth integration |
| Ongoing cost | Keep the file fresh | Own auth, quotas, retries, errors |
| Reuse across channels | Trivial, one file | Google-specific |
| Best for | Batched catalogs, most merchants | Real-time, high-frequency, software-driven |
How this sits with the rest of your delivery
The Content API is one of several feed delivery methods, alongside scheduled fetch and manual upload. It's not a rung above the others; it's a different trade-off. Choose it for real-time control you actually need, and default to a hosted, scheduled feed URL otherwise, including a served enrichment feed URL when you want the data cleaned before Google ever fetches it.
Frequently asked questions
Do I need the Content API, or is a feed URL enough?
A hosted feed URL that Google fetches on a schedule is enough for most merchants and far simpler to run. Reach for the Content API only when you genuinely need per-item, near-real-time updates (fast-moving stock, frequent repricing) that a scheduled fetch can't keep up with.
What's the difference between the products and inventory endpoints?
The products endpoint manages the whole product record, letting you create, update or delete a full offer. The inventory (regional/local) side updates just the fast-changing fields like price and availability without resubmitting the entire product, which is cheaper and quicker for frequent changes.
Does using the Content API mean I don't need a feed at all?
You can run entirely on the API with no feed file, or mix a base feed with API updates for the volatile fields. Many setups use a scheduled feed for the bulk of the catalog and the API only where real-time matters.