Every App Store Connect API key on my team returns 401 NOT_AUTHORIZED for every request, since enrollment. I believe the ASC API entitlement was never provisioned for my team server-side, and I can't find any way to verify or fix that myself. Setup: Individual (paid) Apple Developer Program membership, enrolled 2026-08-12. Team ID 736ZTRRS22, Issuer ID 20166a52-0258-4dbc-80cd-c1e63d55cd56. All agreements Active (Free Apps, Paid Apps, banking, tax). Note: agreement problems surface as 403 REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED, not 401. What fails — everything, identically: GET https://api.appstoreconnect.apple.com/v1/apps → HTTP/2 401 {"errors":[{"status":"401","code":"NOT_AUTHORIZED","title":"Authentication credentials are missing or invalid."}]} Three separate TEAM keys (Admin access), created per the documentation: 7293F9VQS5 (active), plus two since revoked. All 401. One INDIVIDUAL key (YBQLYQZPDATE) with the documented individual payload ("sub":"user", no "iss") — also 401. Individual keys don't use the Issuer ID, so this rules out a wrong Issuer ID or a corrupt team-key record. "Last Used" under Users and Access → Integrations → App Store Connect API has NEVER populated for any key, suggesting my tokens are never resolved to a key record at all. The 401s carry no "id" field in the error object and no X-Request-ID header — only x-apple-jingle-correlation-key (values available on support case 20000139980951, along with screenshots). Control test proving the client side is correct: The identical ES256 signing code, on the same machine and clock, using my APNs key, is ACCEPTED by both api.push.apple.com and api.sandbox.push.apple.com (HTTP/2 400 BadDeviceToken — i.e., authentication succeeded and only my deliberately-invalid test device token was rejected). So key handling, signature format, system clock, and Team ID are all confirmed good. Only the App Store Connect API rejects. Team-key JWT (per "Generating Tokens for API Requests"): header {"alg":"ES256","kid":"7293F9VQS5","typ":"JWT"} payload {"iss":"20166a52-0258-4dbc-80cd-c1e63d55cd56","iat":, "exp":<now+600>,"aud":"appstoreconnect-v1"} Also reproduced with PyJWT and with fastlane — identical 401. Developer Support (case 20000139980951) said API troubleshooting is out of scope for them and pointed me here. Question for Apple engineers: can someone check whether the App Store Connect API entitlement is actually provisioned for team 736ZTRRS22, and whether the key records above are bound to the team? Is there any developer-visible way to see or re-trigger that provisioning? Happy to provide correlation keys / timestamps for specific failing requests.

We are automating subscription review submissions via the App Store Connect API (POST /v1/reviewSubmissions, /v1/reviewSubmissionItems) for an app with many creator-defined in-app subscriptions (App ID: 6777003020). We would appreciate clarification on the following, as the public documentation appears inconsistent with what we observe in production: What is the actual concurrency limit, and does it vary? We received this live error when calling POST /v1/reviewSubmissions: { "status": "409", "code": "STATE_ERROR.ENTITY_STATE_INVALID", "detail": "This resource cannot be reviewed, please check associated errors to see why.", "meta": { "associatedErrors": { "/apps/6777003020": [{ "status": "409", "code": "STATE_ERROR.CONCURRENT_REVIEW_SUBMISSION_LIMIT_EXCEEDED", "detail": "Unable to create reviewSubmission for appId=6777003020 reviewSubmissionType=DEFAULT platform=ANY as maximum limit=5 of concurrency has reached" }] } } } This says the limit is 5. However, your public documentation ("Overview of submitting for review") states: "A platform can have a maximum of two submissions under review at a time: one that includes an app version and one that includes items… without an app version." Could you confirm: Is 5 the correct, current limit for item-only (reviewSubmissionType=DEFAULT, no app version) reviewSubmissions specifically for in-app purchases/subscriptions? Does this limit scale with account size, app size, or number of in-app purchases, or is it a fixed platform-wide constant for every developer account? Is this the same quota referenced by the deprecated subscriptionSubmissions resource's undocumented SUBMISSION_LIMIT_REACHED error, or an entirely separate one? 2. What counts against the limit, and for how long? Does a reviewSubmission count against this limit from the moment it's created (READY_FOR_REVIEW), or only once actually submitted (WAITING_FOR_REVIEW/IN_REVIEW)? If we create a reviewSubmission and never call submitted:true on it, does it still occupy a slot indefinitely, or does Apple expire/release it automatically after some period? Is there a reliable, documented way to cancel/release a reviewSubmission via the API to free a slot on demand, and is that guaranteed to complete promptly? (We're aware of forum reports of CANCELING state persisting for extended periods without resolution.) 3. Can this limit be raised for our account? Is there a process (support request, account tier, or otherwise) to request a higher concurrency limit for automated review submissions, given we manage subscriptions on behalf of many independent creators? Proposed workaround — please confirm whether this resolves the issue: Per your documentation, a single reviewSubmission can hold up to 200 reviewSubmissionItems. Our proposed fix is to stop creating one reviewSubmission per subscription, and instead: Check for an existing, still-editable (READY_FOR_REVIEW) reviewSubmission for the app. If one exists, add the new subscription as an additional item to it (up to the 200-item cap) rather than creating a new reviewSubmission. Only create a new reviewSubmission when none exists in a state that still accepts new items. Could you confirm whether this is in fact the intended/correct usage pattern to stay under the concurrency-5 limit — i.e., does batching multiple pending subscription changes into a single, shared reviewSubmission avoid tripping CONCURRENT_REVIEW_SUBMISSION_LIMIT_EXCEEDED, since it reduces the number of reviewSubmission objects created regardless of how many items each one carries? Or does adding items to an already-WAITING_FOR_REVIEW/IN_REVIEW submission trigger a different restriction we should also account for? Thank you — happy to provide additional logs/request IDs if useful

Hello, We are trying to extract our lifetime app star ratings data from the App Store Connect API but we couldn't find the resource anywhere. We were able to successfully get all app reviews data from this endpoint GET https://api.appstoreconnect.apple.com/v1/apps/{id}/customerReviews based on the official documentation. We validated that we received all reviews, these reviews also include the star ratings. However, the number of star ratings that we see on the App Store console is way less than the one we got from reviews API since star ratings can be submitted without a text review. Any idea where can we get the data of lifetime star ratings using the Connect API ? Thanks !

We manage provisioning for a large number of App IDs across multiple apps via CI, using the App Store Connect API (not session-based Spaceship/Xcode auth). Capability management works well end to end for everything we've tried — Push Notifications, App Groups, Associated Domains, Data Protection, etc. can all be created, updated, and deleted via POST/PATCH/DELETE on /v1/bundleIdCapabilities. Apple Pay is the one exception. We can enable the Apple Pay capability itself via the API the same way as anything else, but there's no way to associate that capability with a specific Merchant ID. /v1/merchantIds exists as its own resource, but nothing in the bundleIdCapabilities or bundleIds schema links to it — no relationship, no include, no dedicated endpoint. In practice this means every new Apple Pay-enabled App ID we provision needs someone to go into the Developer Portal by hand (Identifiers → App ID → Capabilities → Apple Pay → select Merchant ID) before the generated provisioning profile will actually build — otherwise Xcode fails with errors like "doesn't include the Apple Pay capability" / "doesn't support the Merchant ID". Every other capability we use is fully scriptable; this is the one manual step left in an otherwise automated pipeline. Has anyone found a documented (or undocumented) way to do this via the API? If this is a confirmed gap rather than something we're missing, I've filed it as FB24414090 — if you've hit the same thing, adding your own Feedback number to a report on the same gap seems to be one of the few things that actually helps get traction internally, so feel free to reference this thread if you file one too.

Hello Apple Developer Team, I've followed the AppStoreConnect API documentation and created the following: I've created a API Key in App store > Integrations > Teams key, gave the role as admin. Created a valid JWT token When fetching the GET v1/apps, I can see the list of apps. Also I was able to make GET v1/users as well successfully. I've the valid bundle Id and capabilities enabled in the developer portal. Facing an issue while creating an app in App Store using AppStoreConnect API using POST call: This is my ruby script: response = api_request( method: :post, path: "/v1/apps", token: token, body: { data: { type: 'apps', attributes: { name: APP_NAME, primaryLocale: LOCALE, sku: "SKU#{Time.now.to_i}", bundleId: BUNDLE_ID, platform: 'IOS' } } } ) It gives me below error: { "errors": [ { "id": "09b465fc-316f-47b4-9bc3-9c340cb966aa", "status": "403", "code": "FORBIDDEN_ERROR", "title": "The given operation is not allowed", "detail": "The resource 'apps' does not allow 'CREATE'. Allowed operations are: GET_COLLECTION, GET_INSTANCE, UPDATE" } ] } Did anyone was able to successfully create the app in App Store via AppStoreConnect API? Could you please help me identify the root cause for the above issue and provide some inputs so that I could work on resolving them and move forward in the deployment process. Appreciate your help in reviewing this. Thank you, Santosh

Hi, I use the Reporter utility to download sales reports. Periodically I have to update its credentials with a new token. Trying to do this today, I get: $ java -jar Reporter.jar p=Reporter.properties Sales.generateToken Please enter your username: Please enter your password: If you generate a new access token, your existing token will be deleted. You will need to save your new access token within your properties file. Do you still want to continue? (y/n): y Network is available but cannot connect to application. Check your proxy and firewall settings and try again.` Is anyone else having any problems with this? (I'm posting this in "App Store Connect API", but of course this isn't the modern App Store Connect API, it's something that has been around for much longer, and for which I don't see an appropriate forum category.)

Hello, Apple’s documentation appears inconsistent about which App Store Connect API should be used to submit an Apple-hosted Background Asset version for external TestFlight review: In WWDC25 “Discover Apple-Hosted Background Assets”, Apple says that the asset pack version can be submitted using the POST /v1/betaBackgroundAssetReviewSubmissions. In Uploading and versioning Apple hosted background assets, the external beta review instructions link to “Submit an app for beta review,” which uses POST /v1/betaAppReviewSubmissions. These two resources have different behavior. betaBackgroundAssetReviewSubmissions I called the public API with the same resource structure used by the App Store Connect web UI: POST https://api.appstoreconnect.apple.com/v1/betaBackgroundAssetReviewSubmissions { "data": { "type": "betaBackgroundAssetReviewSubmissions", "relationships": { "backgroundAssetVersion": { "data": { "type": "backgroundAssetVersions", "id": "<BACKGROUND_ASSET_VERSION_ID>" } } } } } The public API returned 404 PATH_ERROR: The resource 'v1/betaBackgroundAssetReviewSubmissions' does not exist. However, the App Store Connect web UI uses the private endpoint below with the same payload and receives HTTP 201: POST https://appstoreconnect.apple.com/iris/v1/betaBackgroundAssetReviewSubmissions The public endpoint is also absent from the current App Store Connect OpenAPI specification. betaAppReviewSubmissions I also tested the public POST /v1/betaAppReviewSubmissions endpoint. When I supplied a backgroundAssetVersion relationship, the API returned 409: 'backgroundAssetVersion' is not a relationship on the resource 'betaAppReviewSubmissions'. You must provide a value for the relationship 'build'. The build relationship only accepts the builds resource type, not backgroundAssetVersions. Therefore, betaAppReviewSubmissions can submit an app build but cannot submit a Background Asset version. Could Apple please clarify: Which public API should be used to submit a Background Asset version for external TestFlight review? Is betaBackgroundAssetReviewSubmissions intended to be exposed through the public App Store Connect API? Is the link to betaAppReviewSubmissions in the Background Assets documentation incorrect? When will the public documentation and OpenAPI specification be updated? Thank you.

Hi! I'm observing a problem with ASC webhooks. I have a webhook with all event triggers enabled, and I verified it works: events such as buildUploadStateUpdated and buildBetaDetailExternalBuildStateUpdated are delivered. However, when a screenshot feedback is submitted from an external testing group, no webhook is dispatched (confirmed it does not appear in "Recent deliveries"). The screenshot feedback is submitted successfully, the screenshots appear in the ASC dashboard. Basing on the documentation, I think this event should trigger the BETA_FEEDBACK_SCREENSHOT_SUBMISSION_CREATED webhook.

Hi everyone, I'm investigating an issue related to StoreKit 1 receipt validation and would appreciate any insight from Apple engineers or developers who have encountered this before. Environment StoreKit 1 Consumable In-App Purchase iOS 16 / iOS 17 / iOS 18 (observed on multiple versions) Receipt validation performed on our server Receipt is read from the app bundle after the transaction completes Issue Occasionally, after a purchase succeeds and the transaction reaches the SKPaymentTransactionStatePurchased state, the App Receipt exists and can be decoded successfully, but the receipt contains: { "receipt": { ... "in_app": [] } } The in_app array is completely empty. As a result, our server cannot find the purchased product in the receipt and cannot complete receipt validation. Questions I'd like to understand under what circumstances Apple may return an App Receipt where receipt.in_app is empty. Specifically: Is it expected behavior that receipt.in_app can be empty after a successful consumable purchase? Could this happen if the app reads the receipt before the receipt has been updated? Is there any possibility that calling finishTransaction: before reading the receipt could cause the purchase record not to appear in receipt.in_app? If receipt synchronization is delayed, what is Apple's recommended approach? Wait and retry? Issue an SKReceiptRefreshRequest? Or validate using another mechanism? Are there any documented scenarios where Apple intentionally returns an empty in_app array? Additional Information The transaction state is Purchased. The purchase callback is received successfully. We have confirmed that the receipt file exists. The issue occurs only occasionally and cannot be reproduced consistently. Most purchases contain the expected in_app entry. Any clarification about the expected behavior of the App Receipt or recommended best practices would be greatly appreciated. Thank you!

Hello, I'm developing a consumer iOS app (Capacitor + RevenueCat SDK) and I've been blocked for several weeks on a StoreKit issue: subscription products are never returned to the device, so the Apple payment sheet cannot open. I previously contacted Apple Support. I was told to request a phone call, but my call request was declined because of the topic (StoreKit / in-app purchases). I'm posting here hoping someone from Apple or the community can help. App details App name: Vytal AI Bundle ID: com.ciborgu.vytalai App Store Connect App ID: 6767160542 Team ID: JZF7CR3W8Z Distribution: TestFlight (physical iPhone, France) iOS deployment target: 15+ Subscription product IDs (auto-renewable) vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro All three are in subscription group "Vytal AI" on the correct ASC app (not a typo bundle). Cleared for Sale is ON. Paid Apps Agreement is active. In-App Purchase capability is enabled on the App ID (checkbox is grayed out / locked, which I understand is normal). Problem On a real device via TestFlight: RevenueCat SDK configures successfully (public iOS API key present in build). Purchases.getProducts({ productIdentifiers: [...] }) returns { products: [] } — zero products. Because StoreKit returns an empty array, the Sandbox payment sheet never appears when the user taps Subscribe. This is NOT a UI issue — the native SDK call to Apple returns no products. What I've already verified Bundle ID in signed IPA matches ASC app: com.ciborgu.vytalai Subscriptions exist only on the correct app (not on an old typo bundle com.ciborgue.vytalai) Removed duplicate ASC app; old App ID cannot be deleted ("in use by App Store") but has no IAPs Regenerated EAS provisioning profile for com.ciborgu.vytalai Sandbox tester account configured on device (Settings → App Store → Sandbox Account) Tested without VPN / iCloud Private Relay Reinstalled app from TestFlight after ASC changes Waited for propagation after metadata / availability updates Associated Domains enabled (for deep links) — separate from IAP SDK / integration @revenuecat/purchases-capacitor 13.x Direct StoreKit fetch via Purchases.getProducts() (not only RevenueCat offerings) Same result: 0 products from Apple Expected vs actual Expected: StoreKit returns 3 subscription products in Sandbox; payment sheet opens on purchase. Actual: products array is always empty; no payment sheet. Questions Why would StoreKit return 0 products for valid auto-renewable subscriptions on TestFlight when metadata is "Waiting for Review" / in review — shouldn't Sandbox still return products per TN3186? Is there an ASC configuration state (availability, subscription group localization, missing review screenshot on yearly products, etc.) that causes StoreKit to return zero products even in Sandbox? Is there an internal flag or propagation delay on Apple's side I should ask to be reset for this app/bundle? I'm happy to provide additional logs, a sysdiagnose, or a short screen recording from TestFlight showing the empty product response. Thank you for any guidance — this is blocking App Review (Guideline 2.1) and I cannot test IAP at all. Nathan

Type: Auto-renewable subscription Sandbox Storefront: USA StoreKit successfully loads the subscription product and returns its correct name and price (US$29.99). However, every purchase attempt fails: ASDServerErrorDomain Code=3504 AMSServerErrorCode=3504 "Item not found" client-environment-type=Sandbox storefront-country-code=USA This reproduces both in a TestFlight build and in iPhone Developer Settings > Test In-App Purchases. Please verify the app-product linkage and Sandbox commerce availability for this subscription product. Purchase did not return a transaction: Error Domain=ASDServerErrorDomain Code=3504 "找不到此项目。" UserInfo={storefront-country-code=USA, AMSServerErrorCode=3504, client-environment-type=Sandbox, NSLocalizedFailureReason=找不到此项目。} HKIPO-IAP 11:12:33.712 purchase error: type=StoreKit.Product.PurchaseError, domain=StoreKit.Product.PurchaseError, code=1, description=無法使用項目, failureReason=目前無法使用此項目。, underlying=nil, userInfo={}

we met error when read data from https://api.appstoreconnect.apple.com/v1/salesReports then we found the file format changed before 7/29: api response byte data decompress gz get txt after 7/29: api response byte data decompress gz decompress gz get txt file need to decompress gz twice

Hello, I'm posting here to see if anyone else has experienced an issue whereby a macOS app is searchable under Computers > Mac Apps in Jamf Pro, but when attempting to add the app record the Web UI spins and logs show the following error: "com.jamfsoftware.jss.objects.macapp.MacApp.getNotification()" because "macApp" is null Local installed app is native macOS: DTPlatformName=macosx Mach-O universal x86_64 + arm64 App Store API lookup returns iOS catalog metadata: kind=software features=iosUniversal supportedDevices includes MacDesktop-MacDesktop Expected ABM API result for Mac Apps: kind=mac-software The App Store shows the app as compatible with macOS and iOS, and the app was submitted to App Store Connect as two separate builds - one for each platform. The app is available in the country selected in Jamf Pro, although it is hidden and only accessible with the direct URL. Apple Developer Support have been unable to assist or diagnose the root cause, and have asked us to post here. Thanks in advance, Justin.

from appstoreserverlibrary.api_client import AppStoreServerAPIClient, APIException from appstoreserverlibrary.models.Environment import Environment with open("AUTHKEYLOCATION" ,'rb') as f: private_key = f.read() key_id = "KEYID" issuer_id = "ISSUER_ID" bundle_id = "BUNDLEID" environment = Environment.SANDBOX client = AppStoreServerAPIClient(private_key, key_id, issuer_id, bundle_id, environment) class IosRTDN (APIView): #permission_classes = [ IsAuthenticated] def get(self,request): try: response = client.request_test_notification() print(response) return Response(response) except APIException as e: return Response({ 'error': str(e) }) Using this implementation of the python package from here, it still get a 401 response, from what i see from other implementation ie: JWT, you need a timestamp do you need timestamp too in this case, and where should i put it then?

I hope this message finds you well. I’m reaching out to ask whether specific App Store Connect metrics available in the App Analytics dashboard can also be accessed via the App Store Connect REST API. I have reviewed the official API documentation, but I couldn’t find confirmation regarding the metrics listed below. Could you kindly clarify if the following metrics are available through the REST API? And if so, could you point me to the relevant endpoints or documentation? From the "Usage" group: Installations (Opt-in only) Active Devices Deletions (Uninstalls) From the "App Store" group: Impressions (Unique Devices) Product Page Views (Unique Devices) If these metrics are not available via the REST API, is there an alternative method to programmatically access or export them? Thank you very much in advance for your help and guidance.

Summary Every request to the buildBundles relationship of a build returns HTTP 403, regardless of the build's age or state, even with an Admin-role App Store Connect API key. This blocks access to buildBundleFileSizes, which I need to read the app's download/install size. Error response GET https://api.appstoreconnect.apple.com/v1/builds/{buildId}/buildBundles HTTP/1.1 403 Forbidden { "errors": [ { "status": "403", "code": "FORBIDDEN_ERROR", "title": "The given operation is not allowed", "detail": "The relationship 'buildBundles' has no allowed operations defined." } ] } Environment App Store Connect API (JWT, ES256) API key role: Admin (Team key) JWT payload contains only iss / iat / exp / aud (aud = "appstoreconnect-v1"), no scope field Organization account What works (same key, same token) GET /v1/builds?filter[app]={appId}&limit=5&sort=-uploadedDate → 200 OK GET /v1/apps/{appId}/builds → 200 OK GET /v1/appStoreVersions/{id}?include=app,build → 200 OK So the token itself is valid and can read builds and app store versions. What fails GET /v1/builds/{buildId}/buildBundles → 403 (above) Minimal reproduction (curl) 1) List builds — WORKS (200), returns valid build IDs curl -s -H "Authorization: Bearer $JWT" "https://api.appstoreconnect.apple.com/v1/builds?filter[app]=<APP_ID>&limit=1&sort=-uploadedDate" 2) Read buildBundles for that build — FAILS (403) curl -s -H "Authorization: Bearer $JWT" "https://api.appstoreconnect.apple.com/v1/builds/<BUILD_ID>/buildBundles" -> 403 FORBIDDEN_ERROR: "The relationship 'buildBundles' has no allowed operations defined." $JWT is an ES256 token, aud=appstoreconnect-v1, NO scope claim. Steps to reproduce Generate an ES256 JWT with an Admin-role key (no scope in payload). List builds for an app — succeeds, returns valid build IDs. For ANY returned build ID, GET /v1/builds/{buildId}/buildBundles — always 403. What I have already ruled out Role: the key is Admin, not Developer. Still 403. Build age/state: tested the newest build (uploaded today, processingState = VALID) and builds from several years ago — all return 403. JWT scope: the token has no scope claim (verified by decoding it), so it is not scope-restricted. Still 403. Token validity: the same token successfully reads /v1/builds and /v1/appStoreVersions. Malformed URL / double slash: I verified the request URL is exactly https://api.appstoreconnect.apple.com/v1/builds/{id}/buildBundles with a single slash after the host (no .com//v1). A related thread traced a 403 to a double-slash URL breaking a scoped token (https://developer.apple.com/forums/thread/820203), but that does not apply here: my URL is well-formed AND my token has no scope. Questions Is the buildBundles relationship (and buildBundleFileSizes) actually supported via the public App Store Connect API for organization accounts? If yes, what specific configuration (key type, role, account setting, or entitlement) is required to make GET /v1/builds/{id}/buildBundles return 200 instead of 403? Is there any alternative endpoint to retrieve a build's download/install size (the "size" Apple pushes to the developer, e.g. "206.6 MB, Wi-Fi required")? Thanks in advance.

Hi Apple Developer Forums team, Apple Support suggested that I post this question here. I am trying to retrieve Product Page Views from the App Store Connect Analytics Reports API, but the API returns no report instances even though the App Store Connect Analytics UI shows Product Page Views data. App details: App ID: 6596784990 ONE_TIME_SNAPSHOT request id: 13f72800-f9d4-4001-ba34-e6fac4905170 ONGOING request id: e7e81da4-277e-4773-8362-1b1ba5186661 Report I am trying to use: Report name: App Store Discovery and Engagement Standard Category: APP_STORE_ENGAGEMENT Endpoint: GET /v1/analyticsReports/{reportId}/instances Result: { "data": [], "meta": { "paging": { "total": 0 } } } However, in the App Store Connect Analytics UI, the same app shows: April 2026 Product Page Views: 91 My questions are: Why does the Analytics Reports API return 0 instances for App Store Discovery and Engagement Standard while the App Store Connect Analytics UI has Product Page Views data? Is App Store Discovery and Engagement Standard the correct report for retrieving Product Page Views? If this is the correct report, are there any additional requirements, permissions, report request settings, granularity filters, or data-generation delays that could cause instances to return empty? Is it expected that both ONE_TIME_SNAPSHOT and ONGOING report requests return no instances for this report? Are Product Page Views shown in the App Store Connect UI exposed through the Analytics Reports API, or are they only available in the UI? My expectation is that because the App Store Connect UI shows April 2026 Product Page Views = 91, the corresponding Analytics Reports API report should return at least one downloadable report instance. Could someone confirm the correct API report and retrieval method for Product Page Views?

On 06/25/2026 we began seeing a large number of 500 Internal Server Errors from the Analytics API. The failures are concentrated on the segments endpoint: https://api.appstoreconnect.apple.com/v1/analyticsReportInstances/{id}/segments?limit=200 Summary of the issue Start time: 06/25/2026 (first observed) Endpoint: /v1/analyticsReportInstances/{id}/segments Query used: ?limit=200 Error: HTTP 500 Internal Server Error Scope: massive number of errors across multiple requests and report instances Frequency: sustained and repeated since first occurrence Examples and evidence Large volumes of 500 responses from the segments endpoint beginning 06/25/2026 Logs show repeated failures for multiple report instance IDs (e.g., analyticsReportInstances/xxxxxx/segments) Timestamps and request IDs available in our logs for diagnosis Steps already taken Verified request format and parameters (limit=200) Retried requests with smaller page sizes and different limits Confirmed authentication and API credentials are valid Checked for known outages from App Store Connect status pages (no matching incident found at time of first detection) Requested next actions Please investigate server-side errors for the segments endpoint beginning 06/25/2026 Provide guidance on whether this is a transient outage or a breaking change If possible, share an expected timeline for a fix or any recommended workarounds

Hello, We need help with the App Store Connect Analytics Reports API. App Apple ID: 6476742396 App name: 電話なしで愛車の相場をチェック｜ユーカーパック Endpoint: /v1/apps/6476742396/analyticsReportRequests We are trying to create a ONE_TIME_SNAPSHOT analytics report request to backfill historical App Store analytics data, including App Downloads Standard and App Store Installation and Deletion Standard. Current behavior: GET /v1/apps/6476742396/analyticsReportRequests?limit=200 returns only one ONGOING request: dc54971e-a724-4b5d-939e-3a3fed4c69b4 No ONE_TIME_SNAPSHOT request is visible in the list. However, POST to create a ONE_TIME_SNAPSHOT request returns: 409 STATE_ERROR "You already have such an entity" This state has remained stuck for more than 15 days. Because the ONE_TIME_SNAPSHOT request is not visible, we cannot get the request ID and cannot download historical reports. We suspect there may be an invisible or residual ONE_TIME_SNAPSHOT analyticsReportRequest on Apple's side that blocks new creation but is not returned by the list API. Questions: Is there any supported way to list or retrieve a hidden/residual ONE_TIME_SNAPSHOT analyticsReportRequest for an app? If a ONE_TIME_SNAPSHOT request was deleted or became invisible, can it continue blocking new creation for more than 15 days? Is there a way to clear/reset this state, or should Apple support handle this internally? Are there any additional include/filter parameters for analyticsReportRequests that could reveal the existing ONE_TIME_SNAPSHOT request? The ONGOING request continues to work for recent daily data, but historical backfill is blocked. We already contacted Apple Developer Support under case ID 102911663592, but they replied that this is a technical API topic and suggested posting on Apple Developer Forums. Thank you.

I'm unable to submit my app for review because the App Information / Age Rating section keeps failing to load. When I open My Apps in App Store Connect, I get a red banner that reads "Sorry, something went wrong. Try your request again," followed by a loading spinner that never finishes. The same failure happens through the App Store Connect API: every request to my app's App Info data returns an HTTP 500 "unexpected server error." Everything else about my account and app works normally — I can read my builds, my app versions, and other details with no problem at all. The failure is specific to the App Info / Age Rating data for this one app, which makes me think the App Info record for my app may have become corrupted on your side. This is completely blocking me. My version was previously rejected over an age-rating issue, and I need to open the Age Rating section to correct it and resubmit. I can't do that while this section keeps failing. The problem began at around 14:47 UTC on 23 June 2026 and has been ongoing for more than two hours.