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.

Hello, I noticed the webhook event BUILD_BETA_DETAIL_EXTERNAL_BUILD_STATE_UPDATED does not fire when a build is submitted for external beta review. It is only fired when the review completes. It would be great if we can get notified when an external beta review has started, similar to how we do get notified when a review gets started for the App Store build. Thank you for your time and consideration.

I'm experiencing an issue with the App Store Connect Analytics Reports API where a ONE_TIME_SNAPSHOT report request consistently returns zero report instances (for both Standard and Detailed reports) even though the request itself appears to be valid and active. I want to emphasize: this is not a privacy threshold issue. The problem affects Standard reports, which should not be subject to the same thresholding restrictions as Detailed reports. Environment: API: App Store Connect API Endpoint chain: /v1/analyticsReportRequests → /v1/analyticsReportRequests/{id}/reports → /v1/analyticsReports/{id}/instances Authentication: JWT with Admin role, App Manager scope Reproducibility: 100% — tested across multiple report categories, both Standard and Detailed What I Did: Created a ONE_TIME_SNAPSHOT report request via POST /v1/analyticsReportRequests. The request was accepted and returned successfully: { "data": { "type": "analyticsReportRequests", "id": "4431f553-1091-481a-8312-a2de920df806", "attributes": { "accessType": "ONE_TIME_SNAPSHOT", "stoppedDueToInactivity": false } } } I then fetched the available reports under this request via GET /v1/analyticsReportRequests/4431f553-1091-481a-8312-a2de920df806/reports, which returned multiple report objects. For example: { "data": [ { "type": "analyticsReports", "id": "r15-4431f553-1091-481a-8312-a2de920df806", "attributes": { "name": "App Store Discovery and Engagement Detailed", "category": "APP_STORE_ENGAGEMENT" } } ] } When I try to fetch the actual report instances via GET /v1/analyticsReports/r15-4431f553-1091-481a-8312-a2de920df806/instances, I consistently get an empty response I also tried the Standard version of the same report — "App Store Discovery and Engagement Standard" — and the result is identical: zero instances returned. This rules out Apple's privacy thresholds as the cause, since Standard reports are not subject to the same minimum-user thresholding that Detailed reports are. What I Expected: At least one report instance with a processingDate and a downloadable URL, since the report request is active (stoppedDueToInactivity is false) and was created as a ONE_TIME_SNAPSHOT. Troubleshooting I've Already Done: Waited 24–48 hours after creating the report request before polling for instances, as the documentation suggests data may not be immediately available. Verified the app has active downloads and engagement data (the app is live on the App Store with steady traffic). Tried multiple report categories under the same request (not just APP_STORE_ENGAGEMENT) — all return 0 instances. Tested both Standard and Detailed report variants — both return empty instances, confirming this is not a privacy threshold issue. Created entirely new ONE_TIME_SNAPSHOT requests on different days — same result. Confirmed the JWT token has the correct role and permissions. Verified via GET /v1/analyticsReportRequests that the request status shows stoppedDueToInactivity: false, ruling out an expired or inactive request. Tested with both filtered and unfiltered instance queries (with and without filter[processingDate] and filter[granularity] parameters). Questions: Is there a known delay or prerequisite before ONE_TIME_SNAPSHOT instances become available beyond the ~24 hours mentioned in the docs? Could this be a backend issue where snapshot generation is silently failing without surfacing an error? Are there minimum data thresholds an app must meet before Standard report instances are generated? I've seen several other developers reporting identical symptoms in these forums, across both Standard and Detailed reports, and across both ONE_TIME_SNAPSHOT and ONGOING request types — with no resolution so far. Any insight from Apple engineers would be greatly appreciated. Happy to provide additional request/response logs if needed. Thanks in advance.

I am following the Downloading Analytics Reports guide which consists of five steps: request the ONGOING report generation for the app once list all analytics report requests for the app list all analytics reports based on the analytics report request id :x: list all analytics report instances based on the analytics report id list all segments of the analytics report instance to get the download url I can only complete the third step which returns a list of all available reports. However when I continue with step four, the request for the analytics report instances returns with a response code 200 but the data array is always empty: I am using the Home Screen Widget Installs report but this is also happening for other reports Also changing or omitting the filter doesn't change anything { "data": [], "links": { "self": "https://api.appstoreconnect.apple.com/v1/analyticsReports/{reportId}/instances?filter%5Bgranularity%5D=DAILY" }, "meta": { "paging": { "total": 0, "limit": 50 } } } What could be the reason that the data array is empty and how can I fix it because there is no error message?

Hello everyone, I’m trying to better understand how to safely handle user entitlements around the exact renewal timing for auto-renewable subscriptions. In our app, when a user subscribes through the App Store, our backend retrieves the subscription status using the App Store Server API. We then use the subscription expiration date from Apple to set the user’s entitlement expiration time in our own database. For example, if Apple’s subscription expiration date is: June 24, 8:00 PM we also set the user’s app entitlement to expire at: June 24, 8:00 PM My question is about what happens around the exact renewal moment. From my understanding, Apple attempts to renew an auto-renewable subscription shortly before the subscription expires. However, I’m not fully clear on how precise this timing is in practice, especially from the perspective of a backend service that depends on updated subscription data from Apple. For example, suppose the user’s subscription is expected to renew at 8:00 PM. If the renewal transaction is completed immediately and the updated expiration date is available right away, there is no issue. However, if the renewal transaction or the updated subscription status is delayed by a few seconds or a few minutes due to server timing, network latency, App Store Server Notification delay, or any other processing delay, our backend may still only have the previous expiration date. In that case, our system could temporarily treat the user as expired even though the user expects their subscription to renew automatically. The scenario we are concerned about is: A user has an active auto-renewable subscription. Our backend stores the entitlement expiration time based on Apple’s current expiration date. The subscription reaches the stored expiration time. The renewal is expected around that same time. The updated renewal data has not yet reached our backend. The user temporarily loses access even though the subscription may have renewed or may be in the process of renewing. In this kind of situation, what is the recommended backend design? Should we apply a small internal grace buffer after the expiration time before removing access? For example: a few minutes 30 minutes 1 hour longer Or is it better to strictly expire the user’s entitlement at the exact expiration date provided by Apple and wait until the next verified renewal transaction is received? I understand that Apple has separate concepts such as billing retry and Billing Grace Period, but my question here is more about normal renewal timing and short delays in receiving updated subscription data. For developers who have designed subscription entitlement systems using the App Store Server API and App Store Server Notifications, how do you usually handle this edge case? Do you rely strictly on Apple’s expiration date, or do you keep a short backend-side buffer to avoid incorrectly interrupting access during renewal? Any guidance, best practices, or real-world implementation experience would be appreciated. Thank you.

Hello, I'm having an issue with my App Store Connect API key. The team API key is returning the following error: {'status': '401', 'code': 'NOT_AUTHORIZED', 'title': 'Authentication credentials are missing or invalid.} Account details Account Holder / Admin role Two-Factor Authentication enabled Active developer account with accepted agreements and approved apps Every App Store Connect API key I generate returns a 401 NOT_AUTHORIZED response on all endpoints (/v1/apps, /v1/bundleIds, /v1/devices, /v1/users). I have: What I've tried Revoked and regenerated keys multiple times Confirmed the Issuer ID matches exactly what is shown on the Keys page (I used the copy button) Tested from multiple browsers Verified 2FA is enabled Verified no pending license agreements Tested programmatically using a correctly formatted ES256 JWT (proper R+S raw signature, not DER-encoded) The connection reaches Apple's servers successfully — I receive a JSON 401 response rather than a network error. The JWT is correctly formed. Every endpoint returns 401. Has anyone experienced this issue? Is there something at account level that could be blocking API access entirely? Thank you.

Hello, We are trying to back up App Store Connect Analytics data before an app transfer, and we are seeing two different problems with ONE_TIME_SNAPSHOT requests. Apps com.estmob.paprika (App ID: 596642855) com.estmob.ios.sendy.app (App ID: 1489041568) Issue 1: Paprika snapshot exists, but no instances or segments are ever generated Current snapshot request: Request ID: 4a40d802-5cd4-4bb2-ad53-8539f43c9ce2 What we see: GET /v1/analyticsReportRequests/4a40d802-5cd4-4bb2-ad53-8539f43c9ce2 returns 200 The request has a reports relationship GET /v1/analyticsReportRequests/{id}/reports returns 127 analyticsReports However, for all of those reports, GET /v1/analyticsReports/{reportId}/instances returns no instances Therefore there are still no segments and no downloadable raw files As of May 26, 2026, the state is still: reports: 127 reportsWithInstances: 0 instances: 0 segments: 0 Issue 2: Sendy snapshot was deleted, but creating a new snapshot still fails with 409 Previous snapshot request: Request ID: d40503ae-7a75-4d88-a8a6-115456c333cc Current state: GET /v1/analyticsReportRequests/d40503ae-7a75-4d88-a8a6-115456c333cc now returns 404 Listing analyticsReportRequests for the app shows no visible ONE_TIME_SNAPSHOT request Only the ONGOING request is visible However, creating a new ONE_TIME_SNAPSHOT still fails with: 409 STATE_ERROR "You already have such an entity" We also found this forum thread, which seems related: https://developer.apple.com/forums/thread/759773 Questions For Paprika, does this mean the ONE_TIME_SNAPSHOT is still processing, or is it stuck? For Sendy, is this expected behavior due to a cooldown / retention rule after deleting a snapshot request? If Sendy is blocked by backend state, how long should we wait before a new ONE_TIME_SNAPSHOT can be created? Is there anything else we should check to determine whether the Paprika snapshot will eventually produce instances and segments? This is currently blocking our analytics backup for app transfer. If needed, I can provide additional request/response details. Thank you.