Google Shopping product IDs explained

A Google Shopping product ID is the number Google uses for a product page: the page that groups one product’s offers from many sellers. It is also the key to everything beyond a search result. To get every seller for a product, or its specs and images, you send this ID, so getting it right decides whether the rest of a price monitoring or catalog pipeline works.

This post explains where the ID comes from, what CrawlerData’s endpoints accept, and the mistakes that cost time and credits. Examples come from live API responses we received on 12 October 2026.

Where the product ID appears

In a Google Shopping search result

The Google Shopping API (google-shopping-search) returns a product_id on each result. A search for sony wh-1000xm5 in the US gave us 23 results, each with one:

{
  "position": 1,
  "product_id": "11726664398501807381",
  "title": "Sony WH-1000XM5 Noise Canceling Wireless Headphones",
  "price": { "value": 198, "currency": "USD", "raw": "$198.00" },
  "merchant": "Walmart",
  "link": "https://www.google.com/search?ibp=oshop&q=gid:11726664398501807381&prds=gpcid:11726664398501807381,rds:11726664398501807381%7CPROD_PC_11726664398501807381,catalogid:11726664398501807381,pvo:3,pvt:hg&hl=en&gl=US&udm=28"
}

The link is a Google Shopping product page URL built around the same number: it appears after gid:, gpcid:, PROD_PC_ and catalogid:. In all 23 of our results, every one of those positions held the result’s product_id. The link points to Google, not to the merchant’s site.

In a Google Shopping product URL

If you start from a product page in your browser rather than from an API search, the documented source for the ID is the gpcid value in the URL’s prds parameter. URL-decode it first, because the parameter may contain encoded characters such as %7C:

import re
from urllib.parse import unquote


def product_id_from_url(url):
    """Return the digits after gpcid: in a Google Shopping product URL, or None."""
    match = re.search(r"gpcid:(\d+)", unquote(url))
    return match.group(1) if match else None


print(product_id_from_url(
    "https://www.google.com/search?ibp=oshop&q=gid:11726664398501807381"
    "&prds=gpcid:11726664398501807381,rds:11726664398501807381%7CPROD_PC_11726664398501807381"
))
# 11726664398501807381

Google changes its URL formats from time to time, so if a URL has no gpcid, the reliable fallback is a search for the product’s name or model number.

What the endpoints accept

Two endpoints take the ID:

Both take the same parameters:

A request looks like this:

{
  "endpoint": "google-shopping-product",
  "params": { "product_id": "11726664398501807381", "country": "us" },
  "queue": "live"
}

Send the ID only, not a URL: pull it out with the function above. A full product URL is longer than the 100-character limit, so it is rejected with a 400 VALIDATION_ERROR before any job is created.

The endpoints build the product page from the ID alone. The result echoes it back in search_parameters.product_id and in product.product_id, which makes it easy to join a result to your own records.

Because both endpoints take the same ID, a common pattern is to call google-shopping-product-info once to fill in a catalog record and then call google-shopping-product on a schedule for prices. Check whether you need both: in our test the sellers response also carried the product’s title, brand, description, rating, images and specs. The product info endpoint adds features and a single price.

Product IDs are not GTINs, SKUs or Merchant Center IDs

Several identifiers float around a product on Google, and mixing them up is the most common reason a lookup goes nowhere:

There is no formula that turns a GTIN or SKU into a Google Shopping product ID. The practical route is to search Google Shopping for the brand and model number or a precise title, check that the top result is the product you mean, and save its product_id. A bare GTIN is not a reliable query: in our tests in October 2026, searching for a 12-digit UPC on its own returned unrelated products. That costs one search request (1 credit) per product, once.

Common pitfalls

Storing the ID as a number

This is the one that bites quietly. The IDs in our search were 19 or 20 digits long. That causes three different problems:

• JavaScript numbers. Every ID in our results was above Number.MAX_SAFE_INTEGER (9,007,199,254,740,991). Parse one as a number and it gets rounded: JSON.parse('{"id": 11726664398501807381}').id gives 11726664398501808000, a different product.
• 64-bit integer columns. 11 of the 23 IDs were larger than the largest signed 64-bit integer (9,223,372,036,854,775,807), so a BIGINT column rejects them or overflows.
• Spreadsheets. Spreadsheet apps keep about 15 significant digits. Open a CSV of IDs and save it again, and the IDs can come back as 1.17267E+19 or with the last digits replaced by zeros.

The API returns product_id as a JSON string. Keep it a string everywhere: text or varchar in databases, and quoted or text-formatted columns in CSV files you open by hand.

Assuming one product has one ID

The same model can appear on Google Shopping under several product IDs. In our search for one headphone model, at least five of the first results were listings of that model with different IDs, different headline sellers and different prices. Each ID has its own seller list.

If you are tracking a product, decide which listings count. For competitor price checks the main listing may be enough. For MAP or brand protection, you will usually want every listing that is really your product, because a seller on a listing you do not check will not appear anywhere in your data.

Sending IDs that no longer resolve

Listings come and go. When we sent an ID that does not exist, the job completed in about 8 seconds with this result (trimmed):

{
  "product": { "product_id": "1234567890123456789", "title": null, "images": [], "price_range": null },
  "sellers_count": 0,
  "sellers": [],
  "error": "Product not found"
}

The job’s status was completed and it cost 1 credit, the minimum for a sellers request. That is different from a failed job, which reports "status": "failed" with "credits": 0. Check result.error in your code, and remove or refresh IDs that return it rather than paying for them every day. To refresh one, run the search again and pick the current listing.

Treating an ID as global

Results are fetched for the country you request, and Google Shopping’s listings and sellers differ between countries. An ID you found in US results is not guaranteed to have the same sellers, or any, in another country. Look up IDs in each country you plan to monitor.

Reading too much into the search result’s price

The price and merchant on a search result belong to the single offer Google chose to show on the result card. They are not the lowest price for the product. The sellers endpoint returns every offer for the ID, and its product.price_range gives the minimum and maximum item price across them.

A quick checklist

• Get IDs from google-shopping-search results, or from gpcid: in a product URL.
• Store them as strings. Never as numbers, never in a spreadsheet that reformats them.
• Look them up per country.
• Expect several IDs per model and decide which ones you track.
• Check result.error for "Product not found" and refresh dead IDs.
• Reuse IDs: after the first search, each check is a single sellers request, charged 1 credit per 10 sellers returned (22 sellers = 3 credits).

Where to go next

If you are building a price tracker, competitor price monitoring shows the search-then-sellers workflow end to end. For brand compliance, MAP monitoring covers why every listing of your product matters. If you need specs and images for a catalog, see product catalog enrichment. Searches and product requests cost 1 credit each, and the sellers endpoint costs 1 credit per 10 sellers returned (minimum 1); pack prices are on the pricing page.