App Store reviews policy contract

Reviewed: 2026-08-27 UTC

This is research for a possible own-app connector, not an implementation or an Apple authorization. App Store Connect API access requires case-by-case approval of the Account Holder's account/team request and is governed by terms accepted by that operator in App Store Connect. DynoStatic's separate product rule is that each installation uses only its operator's approved account and installation-local key; Apple does not document approval of each DynoStatic installation. The public documentation supports reading reviews for apps the credential can access and managing the developer's replies. It does not authorize automatic republication of every review on an operator website: Apple says customer reviews may appear in marketing materials only with the reviewer's permission.

Primary sources

App Store Connect API access — Account Holder request, case-by-case approval, team and individual keys, roles, key scope, and manual revocation.
Creating API keys — team versus individual access, one-time private-key download, role authority, and key security.
Role permissions and app access — Customer Support responsibility and limiting eligible users to selected apps.
Generating tokens — ES256 JWT format, team and individual claims, optional request scope, and token lifetime.
List apps — authorized app discovery, stable app resource identity, fields, sorting, and pagination.
List all customer reviews for an app — own-app review fields, filters, sorting, included responses, maximum page size, and cursor links.
Customer review fields — rating, title, body, reviewer nickname, creation date, and territory.
Customer review responses — read, create/update, and delete operations for the developer's one response per review.
Response fields and states — response body, modification date, and PENDING_PUBLISH/PUBLISHED state.
Rate limits — per-key rolling-hour limits, X-Rate-Limit, and 429 RATE_LIMIT_EXCEEDED handling.
Ratings, reviews, and responses — rating accuracy, response guidance, and the reviewer-permission requirement for using reviews in marketing.
Ratings and reviews overview — territory-specific overview ratings, review replacement, public visibility, and rating reset behavior.
Respond to reviews — permitted roles, public/pending response behavior, and reply editing/deletion.
Revoking API keys — irreversible manual revocation for team and individual keys.
App Store marketing identity guidelines — product-page links, approved artwork, trademark treatment, and association boundaries.
Apple developer agreements and guidelines — the current agreement index; the concrete App Store Connect terms are accepted account-side and must be reviewed by the operator because public API documentation does not establish a local-storage license.

All links above returned HTTP 200 when checked on the review date. Apple can change the API, approval process, accepted terms, and marketing rules. Re-review the primary pages and the exact terms shown to the installation operator before any package or readiness promotion.

Access and credential model

Every self-hosted installation operator must already publish the selected app through its own App Store Connect account. DynoStatic must not supply a shared Apple account, API key, proxy, or review-feed service.
The operator's Account Holder must request App Store Connect API access, accept Apple's current terms, and receive case-by-case approval. Possession of an Apple Developer Program membership or an app ID alone does not establish API access.
Prefer an individual key belonging to a dedicated App Store Connect user with the Customer Support role and access limited to the intended app. Apple documents that individual keys inherit the user's app access and permissions. A team key reaches every app in the account and is therefore an unnecessarily broad fallback, even when its role is narrow.
The installation stores the key ID and downloaded P-256 private key encrypted at rest. A team key also needs its issuer ID; an individual key uses sub=user instead. The server generates short-lived ES256 JWTs locally with audience appstoreconnect-v1; review requests must not use a JWT lifetime over 20 minutes. Private keys and signed JWTs never enter browser code, URLs, logs, exports, backups, reports, or support bundles.
Apple documents optional JWT scope entries only for GET request paths. Short-lived read tokens should therefore be scoped to the exact app/review retrieval paths when practical. Reply POST and DELETE mutations must use a separate short-lived JWT with the optional scope claim omitted; DynoStatic must not pretend a documented read scope constrains those mutations. The API key's role and app access remain the primary authority, and no claim can grant authority the key does not have.
This is static-key authentication, not OAuth. There is no refresh token or callback. A disconnected installation destroys its encrypted key locally. Apple documents revocation as an App Store Connect action, so the UI must tell the operator when to revoke a dedicated or compromised key and must not claim remote revocation occurred.

Data and synchronization surface

GET /v1/apps discovers only app resources visible to the credential. The operator selects one exact app; the installation binds its opaque Apple app resource ID to one website-scoped source and never accepts an arbitrary review collection URL.
GET /v1/apps/{id}/customerReviews returns individual written-review resources. Documented attributes are the 1–5 rating, title, body, reviewer nickname, creation timestamp, and App Store territory. A response relationship can include the developer reply. The API does not provide reviewer contact details or evidence that the reviewer authorized off-store use.
The review collection supports territory/rating/published-response filters, date/rating sorting, a maximum page size of 200, opaque links.next cursors, and a reported total. A future adapter must follow only same-origin HTTPS next links, retain the original app authority, impose page/record bounds, and accept a snapshot as complete only after every page succeeds.
The documented review object has a creation time but no review modification time. Apple says a customer's newer rating or review replaces the prior submission. Consequently an implementation must periodically obtain a complete, unfiltered snapshot to detect changed or absent resources; a date cursor alone cannot prove convergence.
App Store overview ratings are territory-specific, include ratings beyond the written reviews returned by this collection, and can be reset without removing old written reviews. DynoStatic must not average the fetched written reviews and label the result the current App Store rating. Apple permits an accurate current app rating in marketing, but this reviewed API surface does not supply the complete current overview-rating fact needed for that claim.
Apple now exposes Apple-generated customer-review summarizations, but the reviewed public guidance does not grant DynoStatic permission to republish those summaries. They are outside this connector decision.

Public presentation and rights boundary

Apple states that customer reviews may be used in marketing materials only when the reviewer has granted permission. A review widget on an app publisher's website is treated conservatively as marketing material. The facts that reviews are publicly visible on an App Store product page and readable through an authorized API are not a republication license.

Review retrieval is not by itself authority to retain a local administrator corpus. A future connector may synchronize reviews into an administrator-only moderation inbox only if the operator's then-current accepted App Store Connect terms expressly permit that local storage and establish an enforceable retention boundary. The implementation record must cite that exact authority and deadline. Otherwise DynoStatic may process a bounded response only transiently for an authorized drill, discard it without persistence, and must not implement an inbox or claim connector readiness.

Even when local retention is authorized, the connector must not automatically publish a review. Public eligibility requires a separate operator attestation that the reviewer granted permission for the exact displayed material. The evidence record must bind the Apple review ID, exact title/body/rating/nickname content hash, permission date, permission scope, and attesting administrator without storing unnecessary private correspondence. Because Apple supplies no reviewer contact channel or permission flag, DynoStatic cannot manufacture or infer this evidence. If the review changes, the prior content-bound permission no longer makes the replacement eligible; the item becomes unpublished until renewed evidence exists.

For any expressly permitted item:

label it as an App Store customer review, show the 1–5 scale and territory when relevant, and link to the operator-verified App Store product page;
preserve the review's meaning and reviewer nickname; do not silently rewrite, translate, excerpt deceptively, or imply Apple endorsement;
use no standalone Apple logo or improvised App Store badge; official artwork is optional only under Apple's current marketing agreement and identity rules, and any Apple mark or badge must carry the then-required trademark credit line; and
remove public eligibility immediately when permission is withdrawn, the source disconnects, the app is no longer authorized, or the upstream review disappears.

The reviewed Apple pages do not state a numeric API-content retention limit or expressly prohibit mixing. They also do not grant a general redistribution, aggregation, or transformation right. Until the exact accepted terms and reviewer permission prove a broader use, the safe provider contract is: no All-in-One Reviews segment, blended rating, local Helpful reactions, curation, AI input/output, translation, summary, static-site export, Import / Export payload, backup, local workspace, migration package, or third-party feed containing Apple-derived review content. An operator who independently possesses reviewer permission may instead create a first-party testimonial through the existing rights-attested path; that is not automatic Apple-source synchronization.

Owner replies

Apple exposes read, create-or-update, and delete operations for the developer's single public response to a customer review. Response resources include body, last-modified time, and pending/published state; Apple notes that publication may take up to 24 hours and deletion is not immediate.

Any future reply workflow must be an explicit, CSRF-protected administrator action on one exact review. It must show that the response is public and that the reviewer is notified. Do not add bulk, scheduled, rule-based, or AI-written replies. Apple's guidance says replies should avoid personal information, marketing language, and spam. After dispatch, reconcile the remote response and state before allowing another mutation; a timeout after dispatch is an unknown result, not proof of failure. The API does not let the publisher delete a customer's review. Offensive or policy-violating reviews are reported through App Store Connect's Report a Concern workflow rather than hidden upstream by DynoStatic.

Quotas, failure, retention, and disconnect

Apple applies a rolling-hour request limit per API key and returns the actual limit and remaining allowance in X-Rate-Limit; documented numeric examples are not guaranteed account limits. Throttle scheduled synchronization, honor 429 RATE_LIMIT_EXCEEDED, and queue bounded retries later rather than burst retrying.
401 requires authentication diagnosis and may require clock correction or credential replacement; 403 means the key, role, or app access is insufficient; 404 cannot by itself prove that an app or review was deleted. Public data must never be refreshed from an error or partial snapshot.
Unless the operator's current accepted terms expressly authorize local retention, persist no Apple review or response content at all. If they do authorize it, keep only the minimum encrypted credential and administrator-only projection for no longer than the documented limit. No public source survives loss of authority. On disconnect, stop jobs first, destroy the private key, unpublish and purge every Apple review/response byte and transient cache, clear cursors, and retain only sanitized audit facts and content-free permission evidence permitted or required for accountability.
Remote key revocation is deliberately manual because a key may serve other operator workflows and Apple documents revocation in App Store Connect. DynoStatic must distinguish local disconnect from confirmed Apple revocation and provide the exact revocation instructions. A revoked key cannot be reinstated.

Testability and authorized readiness drill

Apple does not document an App Store Connect API sandbox for customer reviews. The API overview warns that mutations affect production App Store Connect data. Offline development must therefore use deterministic HTTP fixtures for app discovery, opaque pagination, complete/partial snapshots, replaced and absent reviews, JWT expiry, 401/403/404/429, rate headers, pending replies, ambiguous reply dispatch, disconnect, and purge.

A live readiness drill requires all of the following, with no secret or review body copied into evidence:

an operator-owned App Store Connect account/team whose API request is approved and whose exact current accepted terms have been checked for retrieval, local processing, storage duration, public display, and deletion authority;
a dedicated individual Customer Support key limited to one operator-owned app, with key ID and app/review identities hashed in the drill record;
authorized app discovery, one complete multi-page review snapshot if enough real data exists, bounded token regeneration after forced JWT expiry, and observation of actual rate-limit headers;
independently documented reviewer permission before any review is rendered outside administrator-only storage;
an explicitly authorized create/update/delete reply exercise on a suitable genuine review, acknowledging the reviewer notification and production visibility; if no safe target exists, stop and record the reply portion as blocked rather than manufacture one;
content-update/absence reconciliation using naturally occurring data only—never soliciting fake ratings or reviews to manufacture a test case; and
local disconnect, content purge, manual Apple key revocation, and a failed post-revocation authentication check.

A read-only live drill can validate credentials and retrieval but cannot establish reply readiness or permission-safe public presentation. Until the complete drill passes, no production-readiness claim is justified and no current catalog state should change.

Verdict

approval_required