Apify Public Data & Leads

Google Play App Reviews Search

google_play_reviews_search

Read-only

Pull Google Play Store reviews for Android apps to analyze star ratings, review text, developer replies, and app metadata. Use it for sentiment research and competitor monitoring.

Instructions

Extract public Google Play Store reviews for one or more Android apps, including star rating, review text, reviewer name, developer replies, and app-level metadata (rating breakdown, installs, category, developer).

Behavioral Transparency:

Execution: Network call executed synchronously in the cloud via Apify Actor 'captainhandsome/google-play-reviews-scraper'.
Side Effects: Reads public sources and creates a billed Actor run and dataset on your Apify account.
Authentication: Requires APIFY_TOKEN environment variable.
Latency & Limits: Typical run duration is 15-45 seconds per app; timeout capped at 120 seconds.

Usage Guidelines:

When to use: Use for app-store sentiment research, competitor review monitoring, feature/complaint mining, or tracking developer response rates across one or more Android apps.
When NOT to use: Do not use for iOS App Store reviews, general web search, or employment/job data.
Named alternatives: Use 'linkedin_jobs_search' for hiring/job listings or 'youtube_video_search' for video content discovery; neither covers app-store review data.

Input Schema

TableJSON Schema

Name	Required	Description
`scores`	No	Optional star-rating filter (1-5). Keep only reviews matching any of these ratings, e.g. [1, 2] for negative reviews. Omit to return all ratings.
`app_ids`	Yes	Android package IDs or full Google Play app URLs to pull reviews for, up to 25 (e.g. ['com.spotify.music', 'com.google.android.youtube']).
`keywords`	No	Optional list of words or phrases; keep only reviews whose text contains any of them (case-insensitive). Omit to skip this filter.
`max_results`	No	Maximum number of review records to return per app. Defaults to 25.
`recent_days`	No	Optional recency filter: keep only reviews posted within this many days of now (e.g. 30). Omit to return reviews of any age.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`run`	No
`error`	No
`status`	Yes
`results`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed17 schema fields changedv1.1.0Sep 15, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / keywords / maxItems
```
Added value: +100
```
- addedInput schema / properties / scores / maxItems
```
Added value: +100
```
- addedOutput schema / properties / error
```
Added value: +{
+  "type": "object"
+}
```
- removedOutput schema / properties / results / description
```
Removed value: -"Collection of Google Play review records extracted for the requested app(s)."
```
- addedOutput schema / properties / results / items / properties / app_id / title
```
Added value: +"App package ID"
```
- addedOutput schema / properties / results / items / properties / app_title / title
```
Added value: +"App name"
```
- addedOutput schema / properties / results / items / properties / developer_reply / title
```
Added value: +"Developer reply"
```
- addedOutput schema / properties / results / items / properties / reviewed_at / title
```
Added value: +"Review timestamp"
```
- addedOutput schema / properties / results / items / properties / score / title
```
Added value: +"Star rating"
```
- addedOutput schema / properties / results / items / properties / text / title
```
Added value: +"Review text"
```
- addedOutput schema / properties / results / items / properties / thumbs_up / title
```
Added value: +"Helpful votes"
```
- addedOutput schema / properties / results / items / properties / user_name / title
```
Added value: +"Reviewer name"
```
- removedOutput schema / properties / results / items / required
```
Removed value: -[
-  "app_id",
-  "text"
-]
```
- addedOutput schema / properties / run
```
Added value: +{
+  "type": "object"
+}
```
- addedOutput schema / properties / status
```
Added value: +{
+  "enum": [
+    "success",
+    "empty_unverified",
+    "partial",
+    "error"
+  ],
+  "type": "string"
+}
```
- changedOutput schema / required
```
Previous value: -[
-  "results"
-]New value: +[
+  "results",
+  "status"
+]
```
Addedv1.0.11Sep 13, 2026

TDQS

A3.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses execution model, auth requirements, latency, and side effects, but it openly states it 'creates a billed Actor run and dataset on your Apify account', which contradicts the annotation readOnlyHint=true. Per rubric this is an annotation contradiction, so the behavioral transparency score is grounded to 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear section headers, front-loaded purpose, and clearly separated behavioral and usage sections. Every sentence adds information and nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Combined with the output schema and full parameter descriptions, the description covers execution, billing side effects, authentication requirements, rate-limits, timeout, latency, and alternatives. There are no important operational or selection details missing, aside from the annotation inconsistency.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all five parameters, including constraints and defaults. The description adds no meaningful parameter-specific detail beyond the schema, which fits the baseline 3 for full schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Describes the tool's specific verb and resource: extracting public Google Play reviews with an explicit field list and app-level metadata. It clearly differentiates itself from the sibling tools, none of which target app-store review data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit 'When to use' guidance, explicit 'When NOT to use' exclusions, and names specific alternatives like linkedin_jobs_search and youtube_video_search. The tool is easy for an agent to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.