Blog / API guides

Google Play Store API: App Reviews and Details as JSON

24 Sept 2026Perceptlayer6 min read

To get Google Play data for any public app as JSON, call GET /v1/google-play/product-reviews with the app's package name as product_id. The response carries the app's metadata, rating counts and a list of reviews. Search and details have their own endpoints, and every successful call costs 1 credit.

Does Google have an official Play Store API?

Yes, but it is built for publishers. The Google Play Developer API covers subscriptions and in-app purchases, plus publishing tasks like uploading apps and managing store listings. Its Reply to Reviews API lets you retrieve and reply to reviews of your app, not of apps you don't own.

If you're a developer reading and answering your own reviews, use the official API: it's the right tool and it's authorised for your account. If you want reviews, ratings or listing details for apps you don't publish (competitors, a category, a portfolio you track), you need a different route. That is what the Google Play API here does: it takes a package name or a search term and returns the public store data as JSON.

Data is collected from publicly available sources and returned as found at the time of the call.

What does the Google Play API give you?

The Google Play API has 9 endpoints, all GET, all 1 credit. Reviews and app data live behind product endpoints that share one parameter set. Search is separate and only needs a query. The catalogue spans 248 websites and 1,659 endpoints, and this is one of them, listed under Apps and media.

Each has its own page: Product Reviews, Details, Search, Apps Product, and the books, movies and audiobooks pages. The store parameter takes apps, movies, tv, books or audiobooks on the product endpoints, so one parameter set covers more than Android apps.

How do you get the reviews for an app?

Send the app's package name as product_id to the product-reviews endpoint. The package name is the id= value in the app's Play Store URL, such as com.spotify.music. Authenticate with your key in the X-API-Key header, as described in the authentication docs.

curl "https://api.perceptlayer.com/v1/google-play/product-reviews?product_id=com.spotify.music&store=apps&num=20" \
  -H "X-API-Key: $API_KEY"

You don't have a key yet? Get a free API key: every account gets 1,000 free credits a month after verifying an email address, with no credit card.

What does the response look like?

The response is one JSON object. The top-level keys we recorded for Spotify include search_parameters, app, product_info, about_this_app, categories, data_safety, ratings, reviews, similar_results and pagination. Here is the start of the recorded response, trimmed:

{
  "search_parameters": {
    "engine": "google_play_product_reviews",
    "product_id": "com.spotify.music",
    "store": "apps",
    "hl": "en",
    "gl": "US",
    "num": 20
  },
  "app": {
    "app_id": "com.spotify.music",
    "title": "Spotify: Music and Podcasts",
    "developer": "Spotify AB",
    "url": "https://play.google.com/store/apps/details?id=com.spotify.music&hl=en&gl=US"
  },
  "product_info": {
    "title": "Spotify: Music and Podcasts",
    "rating": 4.3,
    "reviews": 36524909,
    "downloads": "1B+",
    "product_id": "com.spotify.music"
  },
  …
}

The product_info block holds the headline numbers: rating, reviews (the review count) and downloads. about_this_app adds released_on, updated_on and in_app_purchases.

How are ratings and individual reviews returned?

The ratings array holds a star level and a count per entry, and reviews holds one object per review. This is the shape of a review in the recording, trimmed to the fields that matter for analysis:

"ratings": [
  { "stars": 1, "count": 3717244 },
  { "stars": 2, "count": 1064474 }
],
"reviews": [
  {
    "id": "6b8cd845-6fcd-4296-b05e-9e1b3feada62",
    "rating": 1,
    "snippet": "Spotify has a new, horrendous feature where the ending to the song that you are listening to gets cut off by the middle of the next song. …",
    "likes": 491,
    "date": "September 15, 2026",
    "iso_date": "2026-09-15T22:20:33Z"
  },
  …
]

Each review has an id, a star rating, a snippet, a likes count and both a display date and an iso_date. Reviews also carry reviewer profile fields; if you store reviews, think about whether you need them. For sentiment or product research you usually don't.

Which parameters does the reviews endpoint take?

The product-reviews endpoint has no required parameters, but you identify the app with product_id, id or url. The rest narrow the reviews by rating, platform and sort order, and set the language and country. The parameter set is shared with the other product endpoints.

A request for only the one-star reviews, newest first:

curl "https://api.perceptlayer.com/v1/google-play/product-reviews?product_id=com.spotify.music&store=apps&rating=1&sort_by=newest&num=20" \
  -H "X-API-Key: $API_KEY"

To read more than one page, take pagination.next_page_token from the response and send it back as next_page_token. The pagination guide shows a safe loop that stops when the token is missing.

How do you search the Play Store and fetch app details?

For discovery, use GET /v1/google-play/search. It has one required parameter, q (up to 200 characters), and optional store, hl, gl and price. The store values here are apps, movies, books or games; price takes 1 or 2. Details uses the same identifiers as the reviews endpoint.

curl "https://api.perceptlayer.com/v1/google-play/search?q=chess&store=apps" \
  -H "X-API-Key: $API_KEY"

curl "https://api.perceptlayer.com/v1/google-play/details?product_id=com.spotify.music&store=apps&hl=en&gl=US" \
  -H "X-API-Key: $API_KEY"

A common flow is search first, then details or reviews for each package name you want to track. You can try both from the playground on the Google Play API page without writing code. For the exact fields on search and details, run a call there; we only quote fields from the recorded reviews response above.

What does each call cost?

Every Google Play endpoint costs 1 credit per successful call. A failed call costs nothing and returns X-Credits-Used: 0; each successful response carries X-Credits-Used and X-Credits-Remaining so you can track the balance. See credits for the details.

Worked example: tracking 100 apps with one details call and one reviews call each, every day for 30 days, is 100 × 2 × 30 = 6,000 calls = 6,000 credits. That fits inside the Starter pack's 10,000 credits, and the 1,000 free monthly credits cover the first 1,000 of them.

Purchased credits last 12 months, with no subscription and no seats. The pricing page shows what each pack costs.

What can go wrong?

Errors come back as an HTTP status with a JSON body {"error": {"code", "message", "request_id"}}. The ones you'll most likely meet are invalid_api_key (401), insufficient_credits (402), invalid_parameters (422) and rate_limited (429). Rate-limited and temporarily unavailable responses include a Retry-After header with the seconds to wait.

One caveat: requests have no idempotency key. If a client timeout loses the reply, the call may have succeeded and been billed, so don't blindly retry in a tight loop. The errors docs and rate limits list every code, and Retry Web API Calls Without Paying Twice covers the pattern.

If you build a reviews pipeline that runs daily, cache details responses you don't need fresh; Cache API Responses in Python shows how to save credits. Next step: get a free API key, then run the Spotify reviews call above in the playground. For the same pattern on another source, see the Google Maps reviews API guide.

google playapp reviewsapp store dataandroid apps