Google Shopping API for Price Comparison and Seller Data

There are three endpoints, each answering a different question. The search endpoint takes a query and returns up to 40 products a page with prices, matching what a shopper sees on Google Shopping. The product endpoint takes one product's identifier and returns its full detail: every seller offer, variants, specs, reviews and videos where Google shows them. The stores endpoint is the continuation for that same product's remaining sellers, for products with more offers than fit in one response.

All three return structured JSON rather than a rendered page, with the same locale controls: hl for interface language and gl for the country the ranking is computed against, so results reflect the market you're actually comparing prices in.

The product endpoint accepts three different ways to identify a product, depending on what you already have: a catalog_id paired with the original query q, a page_token carried over from a search result for the richest response, or a plain product_id for a leaner response without variants or reviews. Pick whichever you already hold from an earlier call rather than re-searching.

When a product has more sellers than fit on one page, the response carries a next_page_token. That token is only valid on the stores endpoint — the product endpoint itself refuses it — so pagination through a long seller list is a two-endpoint flow: product first, then stores for the rest.

Google publishes its own Merchant Center and Content APIs, but those are built for a different job: managing the product listings you yourself submit to Google Shopping, not reading what's already showing on the results page. If you need to see the comparison a shopper sees — every seller Google surfaces for a given product, with prices — that's the public results page, not a merchant feed.

This API returns exactly that public-facing result set as structured JSON: the same search and product pages a shopper would browse, read programmatically instead of by hand. It's a complement to a merchant feed, not a replacement for one if you're also managing your own Shopping listings.

Yes. Both the product and stores endpoints accept a sort_by parameter with base_price, total_price, promotion or seller_rating, so you can request the seller list already ordered the way you plan to display or compare it, rather than sorting client-side after the fact.

The product endpoint also accepts load_all_stores to fetch every seller in a single response instead of paging through the stores endpoint, which is convenient for products with a short seller list and simplifies the calling code when pagination isn't otherwise needed.

All three Google Shopping endpoints are charged at the same rate per successful call — see the endpoint table above for the current number. Failed calls are never charged, and credits come from the same one-time package used across every endpoint on the platform, so a Shopping-heavy project and a marketplace-heavy project can share one balance.

Yes. All three endpoints are also exposed as MCP tools through the Roketfy Data Engine MCP server, so an agent in a tool like Claude or Cursor can search Google Shopping, pull a product's seller list and page through its stores directly, using the same API token and the same credit balance as your own code.