What it does and who it is for
Real-Time Product Search aggregates product listings from Google Shopping—which itself indexes 35B+ product listings from across the public web—and delivers them through a structured JSON API. Instead of building and maintaining scrapers for Amazon, eBay, Walmart, Best Buy, Target, and dozens of other retailers separately, you make one API call and receive normalized data covering all of them.
The API is a fit for developers building price comparison tools, browser extensions that surface cheaper alternatives, internal dashboards tracking competitor pricing, or data pipelines that feed machine-learning models trained on consumer product trends. Marketers and researchers who need bulk product or review data without a bespoke scraping infrastructure are also a natural audience.
One hardware reality to factor into your architecture up front: the recorded average response latency is 10,550 ms. That is roughly ten and a half seconds per request. This is a consequence of fetching live data from Google Shopping rather than serving a cached database, and it shapes how you should use the API. Real-time lookups triggered on user keystrokes are not a good fit; asynchronous jobs, background enrichment pipelines, and scheduled data pulls are.
Endpoint walkthrough
The API organizes its surface area into eight logical groups. All endpoints follow a consistent REST + GET pattern and return JSON with a top-level status (OK or ERROR), a request_id, and either a data payload or an error object containing a message and code.
Search endpoints
- GET /search-light-v2 — The lighter, faster search variant. Returns product listings, sponsored products, and search filters/refinements from Google Shopping, but omits full product details. Good for building a results list before a user drills down.
- GET /search-v2 — The full search endpoint. Returns everything in
/search-light-v2plus complete product detail objects inline, so you avoid a second round-trip per item if you know you need the detail data. Pagination and infinite-scroll are supported via thepageparameter.
Both endpoints support free-form text queries. Earlier v1 endpoints (e.g., /search) also appear in the endpoint list and handle country-specific routing differences for markets outside the US.
Product details
GET /product-details-v2 accepts a product ID and returns the full detail record: specs, photos, a reviews sample, and additional metadata surfaced on the Google Shopping product page. Use this when a user taps into a specific item after a search.
Product offers
GET /product-offers-v2 retrieves all seller offers for a given product, paginated at approximately 10 sellers per page. Because marketplaces like Amazon and eBay can list the same item from multiple fulfillment sources, a single page may return more than 10 individual offer records. This is the right endpoint for building a "where to buy cheapest" comparison feature.
Price history
GET /product-price-history returns historical price data for a product across the top stores (typically three or four) shown on its Google Shopping page. For trend analysis or alerting users when a product hits a target price, this is essential.
Reviews
- GET /product-reviews-v2 — Paginated product reviews with infinite-scroll support.
- GET /store-reviews — Reviews for a specific retailer/merchant, also paginated.
Having store-level reviews alongside product-level reviews is useful if you are building trust signals or surfacing seller reputation alongside price comparisons.
Deals
GET /deals-v2 searches for deals on Google Shopping with pagination support. Useful for deal-aggregation sites or notification services that alert subscribers when tracked categories go on sale.
Pricing breakdown
The API uses a freemium model distributed through RapidAPI. Overage billing kicks in automatically once the monthly quota is exhausted on paid plans.
| Plan | Monthly price | Requests included | Rate limit | Overage per request |
|---|---|---|---|---|
| BASIC | $0 | 100 | 1,000 req/hr (RapidAPI free-tier cap) | Hard limit — no overage |
| PRO | $25 | 10,000 | 10 req/sec | $0.0030 |
| ULTRA (recommended) | $75 | 50,000 | 20 req/sec | $0.0020 |
| MEGA | $150 | 200,000 | 30 req/sec | $0.0010 |
The BASIC plan requires no credit card and is hard-limited at 100 requests per month—adequate for initial exploration and integration testing but not for any real workload. At $0.003 per request on PRO, and assuming you consume all 10,000 included requests, the effective per-request cost sits at $0.0025 on the base quota. ULTRA halves the overage rate compared to PRO, making it the better value if you expect bursts above the monthly quota. For volumes beyond 200,000 requests, OpenWeb Ninja directs you to a separate Real-Time Product Search (Mega) API or direct contact at [email protected].
The 99% average success rate across the subscriber base is strong given that the API is pulling live web data, where upstream changes to Google Shopping's structure can temporarily break scrapers.
Practical use cases
Price comparison engines are the primary use case the API is designed for. Query /search-v2 to build a results list, then call /product-offers-v2 to enumerate all seller prices for a chosen product in one place.
Competitive pricing dashboards can schedule nightly or hourly batch jobs against /search-v2 for a defined set of product queries or GTINs, store the results, and surface price movement trends alongside /product-price-history data.
Review sentiment pipelines can pull bulk review data via /product-reviews-v2 for NLP analysis—tracking sentiment shifts around a product line or competitor SKUs over time.
Deal alert services can poll /deals-v2 on a schedule and notify subscribers when categories they follow surface discounted items.
Limitations and things to check before integrating
Latency is the most significant constraint. At ~10.5 seconds average, the API cannot be called synchronously in a user-facing request/response cycle without degrading UX. Design with async queues or background workers from the start.
The BASIC free tier is very thin. 100 requests per month works out to roughly 3 requests per day—enough to verify your integration code and inspect response shapes, but not enough to evaluate performance at any scale. Budget for at least the PRO plan during development if you plan realistic load testing.
Country routing. Several endpoint variants exist specifically because Google Shopping's layout differs between the US and other markets. Check which endpoint variant covers your target country; the v2 endpoints appear to be the current recommended path for most regions.
Rate limits on the free plan are imposed by the RapidAPI gateway at 1,000 requests per hour regardless of the monthly cap. Paid plans express limits in requests per second (10–30 RPS depending on tier).
No self-hosted option is mentioned. The API is delivered exclusively through the RapidAPI gateway, so your latency and availability are also a function of that infrastructure layer.
Getting started
Authentication uses two HTTP headers on every request:
X-RapidAPI-Host: real-time-product-search.p.rapidapi.com
X-RapidAPI-Key: <your-rapidapi-key>Subscribe to the BASIC plan on RapidAPI (no credit card required), navigate to the Endpoints tab, and hit "Test endpoint" directly in the RapidAPI Playground—the Search endpoint comes pre-loaded with a default query. Code snippets for JavaScript, Python, Java, Shell, and other languages are available in the right-hand panel of each endpoint.
For error handling, implement retry logic with exponential backoff on 5xx responses and 429s. Validate required parameters before sending to avoid 400s. The structured error body (status, request_id, error.message, error.code) makes programmatic error classification straightforward for errors originating from the API backend, though gateway-level errors from RapidAPI (403, 404, 429) return a simpler {"message": "..."} shape, so your error handler needs to accommodate both structures.
