The App Store Connect Reviews API: A Complete 2026 Reference

The App Store Connect Reviews API lets you read your App Store reviews and post developer replies with two REST endpoints — `GET /v1/apps/{id}/customerReviews` to pull the reviews and `POST /v1/customerReviewResponses` to answer them — authenticated with a short-lived ES256 JWT you sign yourself. There's no OAuth dance, no webhook for new reviews, and one limitation that surprises everyone: the reviews endpoint only returns roughly the last seven days.

This is the App Store side of the story. Google Play does the same job with a completely different mechanism (a service-account OAuth token against the `reviews` resource), and we compare the two review APIs head to head in [App Store vs Google Play review replies](/blog/app-store-vs-google-play-review-replies). Here we go deep on Apple's: how the auth actually works, the exact JSON:API envelope you'll parse, the request bodies you'll send, and the four gotchas that cost people an afternoon each.

Apple doesn't hand you a long-lived API key. Instead you generate an API key in App Store Connect (Users and Access → Integrations → App Store Connect API), download the private key as a `.p8` file exactly once — Apple never shows it again — and use it to sign a fresh JSON Web Token for each burst of requests. Three values come out of that screen and you'll need all three: the Key ID (`kid`), the Issuer ID (`iss`), and the `.p8` private key itself.

The token must be signed with ES256 (ECDSA using P-256 and SHA-256) — Apple rejects anything else — and it has a hard ceiling of 20 minutes. Set `exp` to more than 1200 seconds past `iat` and every call comes back 401. The audience is always the literal string `appstoreconnect-v1`. Here's the anatomy:

In practice you never assemble that by hand. Any JWT library that supports ES256 does it in a few lines — here it is in Node with a signed token you can drop straight into an `Authorization: Bearer` header:

Reviews hang off the app resource. You need the app's numeric ID (the Apple ID from App Store Connect, e.g. `1234567890`), then you hit its `customerReviews` relationship. The API speaks JSON:API, so responses arrive as a `data` array of typed resources, each with an `id`, an `attributes` object, and `relationships` — plus a top-level `links` block for cursor pagination.

A typical read, sorted newest-first, capped at the max page size of 200, with the developer response side-loaded:

What comes back is the JSON:API envelope. Each review carries the fields you'd expect, and the pagination cursor lives in `links.next` — follow it until the key disappears:

Because it's designed to. The `customerReviews` endpoint returns roughly the last seven days of reviews — reviews older than about a week simply aren't in the response, no matter how you sort or paginate. This isn't documented as a hard rule by Apple, but it's the consistent experience across the developer community, and it's the single biggest thing that trips teams building against this API. If you want a durable history, you have to poll on a schedule and store every review as you see it. Miss a week and that week is gone.

That polling requirement is also why there's no push notification for new App Store reviews. The API gives you no webhook, so "tell me when a 1-star lands" is something you build on top yourself: pull on a cron, diff against what you stored last run, and fire your own alert. There's no shortcut in the API for it.

Replying is a single `POST /v1/customerReviewResponses`. The body is a JSON:API resource with one attribute — `responseBody`, the text of your reply — and a `review` relationship pointing at the review you're answering. There's no separate create-vs-update: posting again to the same review replaces your existing response.

The response you get back has a `state` attribute that starts at `PENDING_PUBLISH` and flips to `PUBLISHED` once Apple pushes it live, usually within a day (Apple doesn't publish a guaranteed timeframe). Don't treat a 201 as "the reviewer can see it now." Poll the response resource, or just accept the lag, but tell your users the reply is queued, not posted.

One length note worth building in: Apple publishes no official character limit for `responseBody`, and community testing suggests you can fit a few thousand characters. That's very different from Google Play, which caps developer replies at a hard 350 characters (per Google's Play Console documentation). The [reply rules differ enough per store](/blog/reply-rules-for-every-app-store) that it's worth codifying them once: size the App Store draft generously, but hold the Play draft to 350 or the write fails.

The API is the easy part. The reply itself is the work — and a good one, grounded in the actual bug and offering a real next step, is what moves the needle. Google's own I/O 2019 data showed apps that respond to reviews gain about +0.7 stars on average. Here's the kind of reply that earns it:

Everything above is a weekend to prototype and a quarter to harden. The 7-day window means a durable review store and a reliable cron. The 20-minute tokens mean a signing layer with refresh. Then you want the same thing for Google Play's entirely different OAuth-and-service-account flow, then per-territory language handling, then a way to actually write good replies at volume without a human retyping them all day. That last part is the real cost — the API just moves text; it doesn't know your product or your voice.

That's the gap [ReplyArgus](/features) fills. It runs both APIs for you — the ES256 token rotation, the polling, the 7-day persistence, the JSON:API parsing, the 350-versus-unlimited sizing — and drafts each reply grounded in your knowledge base and past approved replies, in the reviewer's own language across 100+ languages. You approve; it posts. Nothing goes live unattended unless you set an explicit rule. If you're weighing that, our take on [auto-publishing review replies](/blog/is-it-safe-to-auto-publish-app-review-replies) is honest about where to draw the line.

And if you already live in an AI assistant, you can skip the client code entirely. ReplyArgus ships an [MCP connector](/agentic-tools), so the whole read-draft-reply loop becomes a sentence to Claude, ChatGPT, or Cursor — "pull my unanswered 1-stars from the last week and draft replies" — instead of a JWT signer and a pagination loop you maintain forever.