For mobile app developers

App Store and Google Play reviews API: a practical guide

Both stores let you read reviews and post replies through an API. Replylo runs on these two APIs, so this guide covers what Apple and Google document and the parts I had to handle that the documentation leaves to you.

Checked against the official documentation on 15 October 2026.

The two APIs side by side

	App Store Connect API	Google Play Developer API
Credentials	An API key (.p8 file, Key ID, Issuer ID). You sign a short-lived ES256 JWT with it, valid for at most 20 minutes.	A service account JSON key, invited in Play Console with the Reply to reviews permission for the app.
List reviews	`GET /v1/apps/{id}/customerReviews`, paged with a cursor. Filters for rating, territory and whether a published reply exists.	`GET …/applications/{packageName}/reviews`. 10 per page by default, up to 100.
Which reviews	Customer reviews for the app, newest first if you sort by `-createdDate`.	Only reviews with text, only for production, and only those created or modified in the last week.
Reply	`POST /v1/customerReviewResponses`. Creates a reply or overwrites the existing one.	`POST …/reviews/{reviewId}:reply`. Replies or updates the existing reply.
Reply length	No limit stated on the endpoint page.	About 350 characters. Longer replies are rejected and HTML is stripped.
Rate limits	Per API key, per rolling hour. Every response carries an `X-Rate-Limit` header; going over returns HTTP 429.	Per app: 200 list or get requests an hour, 2,000 replies a day.
Language	A `territory` (the storefront), not the review’s language.	A `reviewerLanguage`, and optional machine translation with `translationLanguage`.

Sources: Apple’s pages on listing customer reviews, creating a response and rate limits; Google’s Reply to Reviews guide and reviews.reply reference.

Apple: get a key that can actually reply

Apple’s help page lists Account Holder, Admin or Customer Support as the roles that can respond to reviews in App Store Connect. For API keys it is less clear: developers on the Apple Developer Forums report HTTP 403 when replying with a Customer Support key while the same request works with an Admin key. Reading reviews is not where those reports fail.

I ask for an Admin team key in Replylo for that reason. If you build your own, test one reply with your key before you write the rest. A reply request looks like this:

POST https://api.appstoreconnect.apple.com/v1/customerReviewResponses
Authorization: Bearer <JWT>
Content-Type: application/json

{
  "data": {
    "type": "customerReviewResponses",
    "attributes": { "responseBody": "Thanks for reporting the crash…" },
    "relationships": {
      "review": { "data": { "type": "customerReviews", "id": "<review id>" } }
    }
  }
}

Apple says replies don’t appear on the App Store instantly. The help page mentions up to 24 hours, so a reply missing from the store an hour later hasn’t necessarily failed.

Google: the one-week window

The reviews list only returns reviews created or modified in the last seven days. If your job stops for two weeks, the reviews from the first of those weeks are still in Play Console but no longer in the API. Run the fetch at least daily. Replylo checks every 15 minutes.

Google documents no such window for replying: reviews.reply takes a review ID and a text. Keep the IDs of the reviews you fetch and you can answer them later.

POST https://androidpublisher.googleapis.com/androidpublisher/v3/applications/<package>/reviews/<review id>:reply
Authorization: Bearer <OAuth token for the service account>
Content-Type: application/json

{ "replyText": "Sorry sign-in is failing. Please send your app version…" }

A star rating without text never shows up in the API. The service account needs to be invited in Play Console’s Users and permissions; a Google Cloud service account on its own has no access to your app. The Google Play guide covers that setup.

What a reply tool has to handle

Fetching and posting are two requests. Most of the work is around them:

Duplicates. Both stores give each review a stable ID. Store it and skip what you have already seen, since every poll returns overlapping pages.
Edited reviews. On Google Play an edited review comes back with a new modification time. Decide whether it needs a new reply.
Language. Apple’s territory is the storefront. A review in the Swiss storefront can be German, French or Italian, and plenty of reviews in the US storefront are in Spanish. Detect the language from the text before you reply.
Errors. Treat 401 and 403 as a key problem to show a person, and 429 or 5xx as something to retry later. In my experience a newly invited Google service account can return 403 for a day or two before the permission takes effect.
Length. Count characters before posting to Google Play, so a reply isn’t rejected after someone approved it.
Secrets. The .p8 file and the service account JSON can reply in public under your name. Encrypt them at rest and keep them out of logs.
Review before posting. A wrong reply is public until you notice it. Decide who approves a reply before it goes out, even if that is only you.

Build it or use a tool

For one app with reviews in one language, a scheduled script with the two requests above is a fine weekend project, and the store consoles cover anything it misses. It grows when you add a second app, reviews in languages you don’t write, or the wish to approve replies from your phone.

That is the part Replylo does: it polls both stores, drafts each reply in the reviewer’s language, keeps Google Play replies within the limit, and posts only after you approve. The free plan covers three apps. The support page lists the keys each store needs, and the app review management guide compares the other ways to keep up with reviews.