# App Release Review Impact: Rating by Version (`datagrit/app-release-review-impact`) Actor

Groups App Store and Google Play reviews by app version and shows how each release changed the rating, with significance flags and the complaints that are new in that version.

- **URL**: https://apify.com/datagrit/app-release-review-impact.md
- **Developed by:** [datagrit](https://apify.com/datagrit) (community)
- **Categories:** Business, Developer tools
- **Stats:** 2 total users, 1 monthly users, 0.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

Pay per event

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

### What does App Release Review Impact: Rating by Version do?

App Release Review Impact reads the newest public reviews of Apple App Store and Google Play apps and groups them by app version. For every version you get the review count, the average rating, the star distribution, how the rating changed against the previous version, whether that change is statistically significant, and the complaint terms that are new in that release. It is built for product managers, QA and support leads, app store optimization teams and analysts who want to know which release made users unhappy without reading thousands of reviews.

Review scrapers return one row per review with a raw version string. This Actor returns one row per version, so a regression shows up as a single line with a trend of `regressed` instead of a spreadsheet pivot you have to build yourself.

### Use cases

- **Release monitoring**: run the Actor weekly for your own app and check whether the latest version has a trend of `regressed`.
- **Competitor tracking**: follow the apps of competitors and see which of their releases were received badly and for what reason.
- **Support and QA triage**: `lowStarTopTerms` with its lift against older versions and the sample low-star reviews point to the feature or bug behind a rating drop; on deep Google Play reads `newComplaintTerms` adds a strict statistical flag for terms that are new in the release.
- **Due diligence and market research**: compare release quality across apps of one category, in both stores, in one dataset.
- **Reports**: feed per-version ratings into a dashboard or a spreadsheet without cleaning review dumps.

### How to use it

1. Add apps: App Store IDs (digits such as `1064216828`), `apps.apple.com` links, Google Play package names (such as `com.spotify.music`) or `play.google.com` links. You can mix both stores in one run.
2. Choose the App Store countries to read. Reviews of all chosen countries are merged into one row per version.
3. Set how many newest reviews to read per app and the minimum number of reviews a version needs to get a row.
4. Optionally keep only the latest versions or only the versions that got worse, then run the Actor.

#### How the analysis works

- Reviews are grouped by the app version stored with each review and sorted by version number, not alphabetically.
- Each version is compared with the nearest older version that has at least the minimum number of reviews, so a version with three reviews does not break the chain.
- `ratingDelta` is the change of the average rating and `ratingDeltaMargin` is the half-width of its 95 % confidence interval, in stars. `deltaSignificant` is a Welch two-sample t test at 95 % confidence: the margin is the t quantile for the Welch degrees of freedom times the standard error, so a version with 3 to 5 reviews gets a wide margin, and the variance of each group is floored at 1/12 of a star squared (ratings are whole numbers), so identical ratings never give a margin of zero. Simulated on 20 000 pairs of versions drawn from the same rating distribution, the test flagged a change in 0.3 to 5.4 % of the pairs at 3, 5, 10 and 50 reviews per version (95 % confidence promises 5 %).
- `trend` has five values. `regressed` or `improved`: the change is significant and at least 0.15 stars. `stable`: the change is under 0.15 stars and the margin is at most 0.3 stars, so the sample is large enough to rule out a bigger change. `inconclusive`: the sample cannot tell, either a visible change that is not significant or a margin wider than 0.3 stars; read `ratingDelta` next to `ratingDeltaMargin`. `baseline`: the oldest version of an app, which has no predecessor. The `onlyRegressions` filter keeps `regressed` rows only; when it returns nothing, the status row says how many versions dropped by at least 0.15 stars without enough reviews to call it significant.
- `lowStarTopTerms` lists the five most frequent words and word pairs in the 1 and 2 star reviews of the version, each with `lowStarReviews`, `versionShare` (their share of the version's low-star reviews), `olderShare` (the same share in all older versions) and `lift` (`versionShare` divided by `olderShare`, where `olderShare` is never taken below 1 % or below one review of the older pool, so a term that is absent from a small older pool does not get a lift that merely reflects the size of the pool). `olderShare` and `lift` are `null` when all older versions together hold fewer than 12 low-star reviews, because a share of a handful of reviews says nothing; they are filled on 3 of the 23 rows of the example input and are mostly `null` at 500 reviews per app. The list itself is `null` when the version has fewer than 8 low-star reviews and `[]` when it has 8 or more but no word or pair occurs in at least 4 of them (their complaints are too scattered). On the 23 rows of the example input (500 reviews on six Google Play apps) two runs on 1 October 2026 gave terms on 7 and 8 rows, `[]` on 3 and 1 rows and `null` on 13 and 14 rows; the counts move with the reviews available. Inflected forms of a word are listed once. Where a lift exists, a value near 1 means the term is about as frequent as in older versions and a high value points to a topic that is more frequent in this release.
- `lowStarTopTermsText` is the same list as one readable string (`log (lift 11.1), working (lift 4.2), login`) and is the column of the Version impact table in the Store; `null` when `lowStarTopTerms` is `null` or `[]`.
- `newComplaintTerms` is the strict version of that list: terms that are significantly more frequent in the low-star reviews of the version than in all older versions (one-sided two-proportion test with z of at least 3, at least twice the older frequency, in at least 4 reviews and 3 % of the low-star reviews) and that were not already as frequent in the immediately previous version. `newComplaintTermStats` holds the same numbers per term. An empty array means the comparison was made and no term stands out, which is common on large samples where an old complaint is simply louder; `null` means no comparison is possible (the oldest version, or fewer than 12 low-star reviews in the version or in the older versions together). This field is strict and mostly empty or `null` at the default depth: measured on 1 October 2026 on six popular Google Play apps, it was filled with at least one term on 0 of 23 rows at 500 reviews per app and on 11 of 106 rows at 5000, because the older versions inside the window hold only a few 1-2 star reviews each. Use `lowStarTopTerms` for day-to-day triage and `newComplaintTerms` when you read Google Play at 5000 reviews and want only terms that stand out statistically. Read the terms next to the sample reviews: they point to a topic, not to a confirmed bug.
- `sampleLowStarReviews` holds up to three low-rated reviews that contain those terms. Author names are never collected.

### Example output

```json
{
  "store": "google-play",
  "appId": "com.netflix.mediaclient",
  "appName": "Netflix",
  "version": "9.85.0 build 4 74576",
  "versionRank": 1,
  "reviewCount": 234,
  "avgRating": 4.21,
  "lowStarShare": 0.167,
  "previousVersion": "9.84.0 build 3 74548",
  "previousAvgRating": 4.73,
  "ratingDelta": -0.51,
  "deltaSignificant": true,
  "ratingDeltaMargin": 0.3,
  "trend": "regressed",
  "newComplaintTerms": null,
  "newComplaintTermStats": null,
  "lowStarTopTerms": [
    {
      "term": "movie",
      "lowStarReviews": 8,
      "versionShare": 0.205,
      "olderShare": null,
      "lift": null
    },
    {
      "term": "watch",
      "lowStarReviews": 5,
      "versionShare": 0.128,
      "olderShare": null,
      "lift": null
    },
    {
      "term": "work",
      "lowStarReviews": 5,
      "versionShare": 0.128,
      "olderShare": null,
      "lift": null
    },
    {
      "term": "playing",
      "lowStarReviews": 4,
      "versionShare": 0.103,
      "olderShare": null,
      "lift": null
    }
  ],
  "lowStarTopTermsText": "movie, watch, work, playing",
  "sampleLowStarReviews": [
    "Why are the ads 3× louder than any of the shows?? I damn near blow out my eardrums every single time one comes on and am rushing to turn the volume down.. just to turn it back up in order to hear the shows..."
  ],
  "countries": [
    "us"
  ],
  "found": true,
  "scrapedAt": "2026-10-01T12:27:15.699Z"
}
```

This is a real row from a Google Play run on 1 October 2026 (the 500 newest reviews of Netflix; the sample reviews are shortened to one of three and the star counts and source URL are left out). Real numbers depend on the reviews available when you run the Actor. `versionRank` 1 is the newest version. It is one of the rarer rows: on the same six-app example input (500 Google Play reviews each) two runs on 1 October 2026 gave 23 rows each, 17 of them with a predecessor to compare, and the 17 split into 1 to 3 `regressed`, 0 to 1 `improved`, 1 to 2 `stable` and 11 to 15 `inconclusive` (6 rows are `baseline`); at 5000 reviews per app, 100 comparable rows gave 7 `regressed`, 5 `improved`, 8 `stable` and 80 `inconclusive`. Most versions have too few reviews to call a change, so expect `inconclusive` on most rows and read `ratingDelta` next to `ratingDeltaMargin`. `newComplaintTerms` is `null` here because the older versions in a window of 500 reviews have too few 1-2 star reviews to compare against (see the analysis notes above). Fields that cannot be computed, such as the change of the oldest version, are null.

### Input

- **Apps**: App Store IDs, store links or Google Play package names.
- **App Store countries**: two-letter storefronts such as `us`, `gb`, `de` (`uk` is read as `gb`). A code the App Store does not know, such as `eu`, is reported in the status message and the row `note` and does not stop the run while another code or another app delivers reviews. When none of the codes is valid and no other app delivered anything, the run fails with a message that names the codes and the app gets a free status row. Ignored for Google Play apps.
- **Google Play country** and **language**: which Play storefront and interface language to read.
- **Reviews to read per app**: 50 to 5000. Google Play serves up to 5000 newest reviews. The App Store feed pages 50 reviews at a time up to 500 per country, but it often stops answering after the first page, so plan for 50 to 500 reviews per App Store country.
- **Minimum reviews per version**: versions below this limit are left out because averages over a handful of reviews are noise.
- **Only the latest N versions** and **Only versions that got worse**: narrow the result.
- **Maximum version rows**: stops the run after this many rows.

### Pricing

You pay per version row returned. Apps that are not found, apps without enough reviews and duplicates produce a free status row with `found: false` and a note, so you are never charged for an empty result. The price per row is set on the Actor page and shown before you run it; set a maximum charge per run in the Apify console to cap spending, and the Actor stops cleanly when the limit is reached. Reading the reviews costs nothing extra.

### Good to know

- Rating changes depend on how many reviews a version has. Google Play runs reach back several versions (in our check of 1 October 2026: Spotify 4 versions and Reddit 3 versions from 500 reviews each, 12 to 315 reviews per row). A busy App Store app with only the first feed page (50 reviews) usually gives one or two rows, the oldest of them a `baseline` without a rating change and with a `note` saying that the data is partial. Add countries, lower the minimum or use the Google Play listing of the same app for a longer history, and read the `reviewCount` next to every change.
- A version appears only in the reviews written while it was installed. A new release collects reviews over days, so the newest row can rest on a few reviews.
- Google Play shows the version the reviewer used when writing, and a share of reviews has none. Measured on 2 October 2026 on 400 to 500 reviews per storefront: 62 to 93 % in the United States for 22 apps (Snapchat 62 %, Telegram 64 %, Spotify 85 %, Duolingo 93 %) and 53 to 84 % in Germany, Russia, Japan and Brazil; the lowest read was Snapchat in Indonesia with 30 to 32 %. The App Store feed gave a version on every review we read: 100 % on 2,437 reviews from 18 storefronts (measured 2 October 2026). The coverage is therefore judged per storefront (one country for Google Play, each country for the App Store) against a threshold per store, 20 % for Google Play and 90 % for the App Store: at or above it the rows are returned and, when some reviews have no version, the `note` says "us: 190 of 200 reviews carry an app version, so the version statistics of this storefront rest on fewer reviews"; below it that storefront is left out of the statistics, named in the `note` and in the status message (separately for storefronts with no version at all and for those under the threshold), and its country disappears from `countries` and `sourceUrl`, also on the status row of an app with no qualifying version. The app fails only when no storefront reaches the threshold. The status message of each run reports how many reviews carried a version.
- If a store changes its format so that no review can be read or no version is found, the app gets a status row that says so, and the run fails instead of returning empty rows when no other app delivered anything.
- The App Store review feed sometimes answers with an empty page instead of an error, and it does so unpredictably, also for pages that were served a moment earlier. The Actor retries an empty first page up to six times with growing pauses and compares the result with the number of ratings the store lists; an empty page in the middle of the feed gets two more tries. Everything that goes wrong while one app is read shares a budget of 75 seconds for that app: the pauses between tries of empty pages, the waits before retrying a request that the store answered with HTTP 429 or a server error (a `Retry-After` header is honoured only while it fits into what is left of the budget) and the time spent in attempts that failed. An app gets at most 75 seconds, and at most an equal share of what is left of a 150-second budget for the whole run (with three apps the first one gets 50 seconds), and never less than 9 seconds, so an app that has not been touched yet always keeps enough time to make its requests and a source that hangs for the first apps cannot take the attempts of the next one. Each attempt is limited to 25 seconds by a hard deadline (and to what is left of the budget), so a source that accepts the connection and never answers costs that app 75 seconds in total, not minutes per request. Requests that succeed are not counted, so a large read of a healthy source is not cut short; the run also spends time on a 1.2 second gap between App Store requests. Measured on 1 October 2026 with the App Store host set to accept connections and never answer and Google Play live, on three apps (two App Store apps and `com.reddit.frontpage`): each App Store app used 50.0 s and got a status row, then `com.reddit.frontpage` delivered 500 reviews from Google Play in 2.2 s (102 s for the run; with a cap of 150 s for the run shared in turn, the third app used to get no request at all). With the App Store feed answering 200 without entries for the three countries `us`, `gb` and `de` the App Store app used 81.5 s (73 s of pauses) and Google Play delivered its 500 reviews afterwards (4 s). An empty page is not taken as the end of the feed: later pages are tried too (measured: pages 1 and 2 empty, page 3 with 50 reviews in the same minute). The `note` tells a gap (an empty page followed by a served page, so those reviews are missing from the window) apart from an empty page after the last served one (the oldest reviews of the window may be missing). An app whose feed stays empty gets a free status row that says the feed returned no reviews and how many tries were made (fewer than six when the budget ran out), which does not show whether the app has written reviews; run again to read them. A failed app or country keeps what was already read, whatever the failure was (an empty feed, a transport error, an HTTP error such as 403 or a changed format of the feed in one of several storefronts): the storefronts that were read stay in the version rows, and the `note` names the storefront that was not read and why. An app is a failure only when none of its storefronts could be read. The status row carries the app name, the storefronts that were looked up and the store page whenever the store answered the lookup. The other apps are delivered and the run succeeds. The same holds for any other error of one app (a store answering with an HTTP error, a changed format): it gets a free status row and the other apps are delivered. The run ends as failed only when no app delivered any reviews. If the feed stops partway (in the App Store, or in Google Play with an HTTP error such as 403 or a changed payload after the first batch of 200 reviews), the reviews read so far stay in the version rows and the `note` carries the number of reviews that arrived and the reason reading stopped; an error before the first review is a failure of that app. If the store answers with reviews but none of them passes validation (for example the rating field changed its format or was renamed, so the entries carry no rating at all), the app gets a status row that says so and the run fails only when no other app delivered reviews. When that happens in one of several storefronts, the other storefronts stay in the version rows and the `note` names the storefront and the number of entries that failed validation (all of them, or how many of the entries it returned); the version statistics of that storefront then rest on fewer reviews. Entries of the App Store feed that lack the rating field are counted as invalid in the same way, never skipped silently, and a page whose entries all lack it is not read again as if it were empty. Google Play entries that fail validation are reported the same way ("us: 100 of 200 review entries failed validation and were left out"). Google Play can also answer 200 without a single review. The Actor then asks up to three times (pauses of 3 and 5 seconds, inside the budget above) and compares the result with the rating count in the app page: with 50 or more ratings listed the app gets a free status row that names the count and the number of tries and says that this does not show whether the app has written reviews, and the run fails when no other app delivered reviews; with fewer ratings, or none listed, the status row says that the app may have no written reviews yet. An empty batch in the middle of the Google Play reviews gets one more try, and if it stays empty the `note` says that reading stopped after that many reviews and that the oldest reviews of the window may be missing. A reviews payload whose shape is not a list is a changed format, not an empty app. The version stored with a review is the field the grouping stands on, so it is checked on every app, however few reviews were read: when no storefront of an app reaches the threshold above (no review carries a version, or fewer than 20 % of the Google Play reviews, or fewer than 90 % of the reviews of each App Store country), the app gets a free status row that says the source may have changed (never advice to lower the filters), and the run fails when no other app delivered reviews. When a storefront reaches it, the `note` of every row and of the status row says how many of the reviews of that storefront carry a version (for example "us: 209 of 240 reviews carry an app version, so the version statistics of this storefront rest on fewer reviews."), because the review counts and averages of a row rest on those reviews only; Google Play leaves the version empty on a share of reviews (31 of 200 in the Spotify sample we checked).
- Only public review pages are read. No account, cookies or personal data are involved.

### FAQ

**Is it legal to scrape app store reviews?** The Actor reads public review data from the same public endpoints the stores use for their own pages and the App Store review feed. It collects no data behind a login and does not store reviewer names.

**How many reviews can I get?** Up to 5000 per Google Play app. The App Store feed allows up to 500 per country, but it often serves only the first 50, so add countries or run again for more.

**How often should I run it?** Weekly or after each release. A scheduled run shows the newest version as soon as it has enough reviews.

**Why is a version missing?** It has fewer reviews than the minimum, or it is older than the reviews that the store made available in this run.

**Why is a visible drop not marked regressed?** Then the trend is `inconclusive`: with this few reviews the drop cannot be told from chance (see `ratingDeltaMargin`). `stable` is used only when the change is under 0.15 stars and the sample is large enough to rule out a bigger one.

**Something looks wrong in the data.** Open an issue on the Actor page with the input you used and the run link.

### Related Actors

Use it together with other datagrit Actors that watch public company and product signals, for example the Hacker News hiring history Actor, to connect release quality with hiring and product activity.

# Changelog

This Actor's version history is a separate document: https://apify.com/datagrit/app-release-review-impact/changelog.md

# Actor input Schema

## `apps` (type: `array`):

App Store IDs (digits, e.g. 1064216828), apps.apple.com URLs, Google Play package names (e.g. com.reddit.frontpage) or play.google.com URLs. Mix both stores freely; every app is analyzed separately within its own store.

## `countries` (type: `array`):

Two-letter App Store storefronts to read for App Store apps (us, gb, de, ...; uk is read as gb). A code the App Store does not know is reported and skipped. Reviews of all selected countries are merged into one row per version. The App Store feed exposes at most the 500 newest reviews per country and often only the first 50. Google Play apps ignore this field.

## `googlePlayCountry` (type: `string`):

Two-letter Google Play country used when reading Google Play apps.

## `googlePlayLanguage` (type: `string`):

Language code of the Google Play page (en, de, pt-br, ...). It sets the language of the interface, not a filter on review language.

## `maxReviewsPerApp` (type: `integer`):

Newest reviews to read per app. For App Store apps this limit applies per country; the feed pages 50 reviews at a time up to 500 and often stops after the first page. Google Play allows up to 5000, and more reviews reach further back in version history there; the strict newComplaintTerms list fills mainly at 2000 to 5000.

## `minReviewsPerVersion` (type: `integer`):

Versions with fewer reviews are left out, because averages over a handful of reviews are noise. Rating changes are always compared with the nearest older version that passes this limit.

## `latestVersions` (type: `integer`):

Keep only the N newest versions of each app that pass the minimum reviews limit. Zero keeps all of them.

## `onlyRegressions` (type: `boolean`):

Return only versions whose average rating dropped by at least 0.15 stars against the previous version and the drop is statistically significant (95 % confidence).

## `maxItems` (type: `integer`):

Stop after this many version rows in total across all apps.

## `proxyConfiguration` (type: `object`):

Apify Proxy is on by default. The App Store review feed sometimes answers with an empty page; the Actor retries an empty first page up to six times, gives every app a budget of at most 75 seconds for everything that goes wrong (pauses after empty pages, waits before retrying HTTP 429 or server errors and the time spent in attempts that failed; each attempt is also cut off after 25 seconds), limited to an equal share of the 150 seconds of the whole run and never below 9 seconds so that apps that were not touched yet can still be read, and gives an app it cannot read within its budget a free status row. If the proxy cannot be created the run continues without it.

## Actor input object example

```json
{
  "apps": [
    "1064216828",
    "com.reddit.frontpage"
  ],
  "countries": [
    "us"
  ],
  "googlePlayCountry": "us",
  "googlePlayLanguage": "en",
  "maxReviewsPerApp": 500,
  "minReviewsPerVersion": 10,
  "latestVersions": 0,
  "onlyRegressions": false,
  "maxItems": 200,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}
```

# Actor output Schema

## `results` (type: `string`):

One row per app version with rating change and complaints.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "apps": [
        "1064216828",
        "com.reddit.frontpage"
    ],
    "countries": [
        "us"
    ],
    "googlePlayCountry": "us",
    "googlePlayLanguage": "en",
    "maxReviewsPerApp": 500,
    "minReviewsPerVersion": 10,
    "latestVersions": 0,
    "onlyRegressions": false,
    "maxItems": 200,
    "proxyConfiguration": {
        "useApifyProxy": true
    }
};

// Run the Actor and wait for it to finish
const run = await client.actor("datagrit/app-release-review-impact").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "apps": [
        "1064216828",
        "com.reddit.frontpage",
    ],
    "countries": ["us"],
    "googlePlayCountry": "us",
    "googlePlayLanguage": "en",
    "maxReviewsPerApp": 500,
    "minReviewsPerVersion": 10,
    "latestVersions": 0,
    "onlyRegressions": False,
    "maxItems": 200,
    "proxyConfiguration": { "useApifyProxy": True },
}

# Run the Actor and wait for it to finish
run = client.actor("datagrit/app-release-review-impact").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "apps": [
    "1064216828",
    "com.reddit.frontpage"
  ],
  "countries": [
    "us"
  ],
  "googlePlayCountry": "us",
  "googlePlayLanguage": "en",
  "maxReviewsPerApp": 500,
  "minReviewsPerVersion": 10,
  "latestVersions": 0,
  "onlyRegressions": false,
  "maxItems": 200,
  "proxyConfiguration": {
    "useApifyProxy": true
  }
}' |
apify call datagrit/app-release-review-impact --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,datagrit/app-release-review-impact"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/Qbeysegzumsd2Fo6w/builds/oZNutIV3uxBjg02Mn/openapi.json