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.

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?

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.

Hi! We are trying to put the game The Ouroboros King on the Epic Mobile Store (I can share SKU ID and AppleID if it helps). We followed all the steps: the game has been notarized, tested on iOS (via TestFlight), and associated with the Epic Game Store alternative marketplace in App Store Connect. After all of that, we can see the binary available on the Epic portal for the Epic Team to test, but when they try to download it, it says App Not Available. We've tried multiple things with them, but it seems stuck, and they told us to try with Apple Support. So here I am! Their engineers see iOS making an API call to fetch the data to display for the install confirmation popup. But it's failing with: "errors": [{ "id": "ORHPEIOCABRJX6DYPA6SJSLGK4", "title": "Resource Not Found", "detail": "Resource with requested id was not found", "status": "404", "code": "40400" }] Can someone have an idea on how to fix the situation? Thank you!

Hello all, I'm currently using Apple Connect API to retrieve download info from my app. Namely I'm using App Store Installations and Deletions under the Analytics Reports API, using an ONGOING request with daily granularity. Unfortunately, the data received is not matching the data from apple store connect UI. Recently I found this article, from apple help documentation for Analytics Reports API that states the following: "(..) Some usage reports are not generated if minimum thresholds are not met (...)" and "(...) Additionally, a small amount of statistical noise is added to metrics, preventing the reverse-engineering of individual activity while preserving accuracy at scale." I kindly ask if: What is stated in 1. happens often within the report generated from App Store Installations and Deletions. If yes, do you have any idea of the percentage, so we take that into account when showing our metrics? What is stated in 2. happens often within the report generated from App Store Installations and Deletions. If yes, how to handle the statistical noise? Discard events with the field "count" < 5, for instance? Thank you very much, HH DOCs: https://developer.apple.com/documentation/analytics-reports/app-installs https://developer.apple.com/help/app-store-connect-analytics/overview/analytics-reports-api https://developer.apple.com/documentation/analytics-reports

Hello all, I'm currently using Apple Connect API to retrieve download info from my app. Namely I'm using App Store Installations and Deletions under the Analytics Reports API, using an ONGOING request with daily granularity. Unfortunately, the data received is not matching the data from apple store connect UI. Under the functional doc for the report-generated-fields (https://developer.apple.com/documentation/analytics-reports/app-installs), I see the following descriptions: Field Date: "Date on which the event occurred. For weekly and monthly instances, this column represents the first day of the week and month, respectively." Field App Download Date: "The date on which the app was downloaded onto the device. This field is only populated if the download occurred in the previous 30 days, otherwise it is null." Since I am using daily granularity, could you clarify exactly what is the functional difference between the two fields? Which one should I use to show the metric total downloads per day? Since the field App Download Date becomes null after 30 days, if that is the one to use, how could I gather historical data from a ONE_TIME_SNAPSHOT request? Thank you very much, HH DOCs: https://developer.apple.com/documentation/analytics-reports/app-installs https://developer.apple.com/documentation/analytics-reports

We are integrating with the App Store Connect API to automate ingestion of monthly revenue data for our app (MUBI), and are trying to understand whether there is a report available via the API that provides settled financial data at the individual subscriber level. From our research so far: v1/financeReports with reportType=FINANCE_DETAIL (region Z1) gives us actual settled Partner Share and Extended Partner Share at Transaction Date granularity, but rows are aggregated by SKU + Country + Date, there is no subscriber or individual transaction identifier v1/salesReports with reportType=SUBSCRIBER gives us an anonymised Subscriber ID and Developer Proceeds per billing event, but Developer Proceeds is an estimate using rolling average exchange rates and does not reflect actual settled amounts or withholding tax deductions The App Store Server API (/inApps/v2/history/{transactionId}) provides price and currency per transaction per customer, but requires a transactionId per user, is not designed for bulk analytical pulls, and again does not expose settled Partner Share Is there a report or endpoint we have missed that provides settled Partner Share at the individual subscriber or transaction level? Or is the separation of financial settlement data from subscriber identifiers a deliberate platform decision, e.g. for privacy reasons? Any guidance or suggestions on the recommended approach for reconciling subscriber-level data with actual settled revenue would be much appreciated.

Our app was approved for distribution yesterday, however our In-App Purchase subscription products have been in Waiting for Review status for several months, without the ability or option to manually connect to the app when submitting for review. As a result the App Store is incorrectly displaying our app as a $6.99 one-time purchase instead of Free with In-App Purchases. What can be done to connect the app to the subscriptions.

Context We're handling App Store subscriptions on the server side using App Store Server Notification v2. Our pipeline currently identifies each event by transactionId and originalTransactionId. A few notes about our client: Our app is built with Flutter and uses the standard in_app_purchase plugin layer to drive App Store purchases (StoreKit 1 under the hood). We have not migrated to StoreKit 2 on the client yet. We have not been setting SKPayment.applicationUsername on outgoing purchases, so every transaction we've ever produced has appAccountToken: null in its v2 notification. This question is purely about what the server-side notification can tell us, given the current client state above. What we're trying to figure out A user can resubscribe to an expired subscription in two different places: In-app — the user opens our app and re-purchases through our normal in-app purchase flow. App Store — the user goes to Settings → Apple ID → Subscriptions and resubscribes from the system UI, without ever returning to the app. Both paths trigger a SUBSCRIBED notification (subtype RESUBSCRIBE) with structurally identical payloads as far as we can tell — same shape for data.transactionInfo, data.renewalInfo, etc. From the notification alone we can't decide which path produced it. The reason this matters: in our system, the two paths require different business handling: In-app path: the user may have signed in to a different business account in our app. The new subscription should be attributed to whoever paid in the app just now, not to the previous owner of originalTransactionId. App Store path: there is no in-app signal, so the business owner can only be inferred from the previous originalTransactionId mapping. If we get it wrong, the subscription's entitlement ends up on the wrong business account. What we do today Because we can't tell the paths apart from the notification, we defer processing for a few minutes and check whether an in-app order for the same transaction has arrived in the meantime: If an in-app order shows up → it's the in-app path; attribute to the in-app account. If nothing shows up after the delay → assume App Store path; fall back to the previous owner mapping. This works but adds latency to entitlement activation and forces us to build a deferred-retry queue with idempotency against the in-app callback path. Possible direction: appAccountToken / applicationUsername We noticed that v2 notifications carry transactionInfo.appAccountToken, and the docs suggest that StoreKit 1's SKPayment.applicationUsername (when it's a valid UUID) is mirrored into this field. In theory, if we start setting it on every in-app purchase from the Flutter client, the field could double as a path discriminator on the server: appAccountToken != null → in-app path (only the app can set it), and we even get the business user id for free appAccountToken == null → App Store path (no UI to populate it) But we have some open questions before committing to this direction: Questions Is there an existing signal in ResponseBodyV2 / JWSTransactionDecodedPayload / JWSRenewalInfoDecodedPayload that distinguishes these two paths, that I might be missing? Can the same distinction be obtained via getAllSubscriptionStatuses / getTransactionHistory / any other Server API endpoint? Is applicationUsername (StoreKit 1) still a reliable way to populate appAccountToken on v2 notifications today? Specifically: Are there format constraints beyond "valid UUID" that cause Apple to drop the value? Any known differences between sandbox and production in how it's mirrored? Does the App Store path ever strip or overwrite a previously-set value when the same originalTransactionId is reused? For existing subscriptions where applicationUsername was never set (which is all of ours today, since we've never polient), is there any way to retroactively distinguish the in-app vs App Store path? Or is timing-based deferred matching theonly option for that cohort, even after we start setting the value on new purchases? If neither (1) nor (2) is currently possible, is the timing-based heuristic we use today the pattern Apple expects developers to follow, or is there a recommended approach we're missing? A small suggestion, if it turns out there's no existing way If the information genuinely isn't exposed today, it might be worth surfacing a salesChannel-style field on the transaction, similar to what Google Play Developer API exposes on Order.salesChannel (IN_APP, PLAY_STORE, etc.). That would let server-side handlers route each event to the correct business owner immediately, regardless of whether appAccountToken was set, and would also cover legacynt never had a chance to populate it. Thanks — happy to share sample payloads or more detail if helpful.

We've been pulling daily download reports (First-time downloads + Redownloads) via ONGOING requests and noticed random missing days in our data — in April alone, we were missing the 11th, 14th, 23rd, and 27th. After debugging, here's what's actually happening: Apple sometimes publishes two consecutive ONGOING instances with identical content (same processingDate → same Date in the CSV) The day after a duplicate, the CSV skips a date entirely — that data is simply never published Those missing days are gone forever. There's no way to recover them via API Does this happen to anyone else? Do you know if there is a way to recover missing data?

Hello, I am experiencing an issue with the App Store Connect API where a ONE_TIME_SNAPSHOT analyticsReportRequest appears to be stuck in a ghost state for our app. The issue is as follows: An initial POST to /v1/analyticsReportRequests was made successfully on Thursday 1st May 2026, returning request ID A subsequent GET to /v1/analyticsReportRequests/ returns: Status: 404 NOT_FOUND Detail: "There is no resource of type 'analyticsReportRequests' with id" However, a new POST to /v1/analyticsReportRequests returns: Status: 409 STATE_ERROR Detail: "You already have such an entity" A GET to /v1/apps/626148774/analyticsReportRequests?filter[accessType]=ONE_TIME_SNAPSHOT returns: Status: 200 OK data: [] (empty — total: 0) This is contradictory — the API simultaneously reports that the request does not exist (404) and that it already exists (409), while the app-level listing confirms no active requests. This has been ongoing for a week. As a workaround we have created an ONGOING request instead, but we still require the ONE_TIME_SNAPSHOT to be unblocked for historical data backfill purposes. Could you please investigate and manually clear this ghost request on your backend? Original POST date: Thursday 1st May 2026 Thank you!

Hi all, I made an initial ONGOING POST request to the Analytics Reports API, received a request ID, and used it to list available reports. I've waited beyond the documented 24–48 hour generation window, but I'm not seeing the two subscription reports I need from the Commerce category: Subscription State Subscription Event Interestingly, the other three Commerce reports are available (both standard and detailed): App Store Purchases App Store Pre-Orders App Downloads Does the absence of the subscription reports indicate they're not enabled for this account? If so, is there a separate step required to make them available? Thanks

Hello, I have an app on the App Store that offers in-app purchases (consumable, non-consumable) and auto-renewable subscriptions. My goal is to verify the validity of purchase receipts on my own backend server, to prevent fraudulent transactions. My questions: Does Apple provide an API that allows my server to validate a receipt (the one generated after a purchase) and confirm whether it is genuine? For auto-renewable subscriptions, can I retrieve renewal dates, expiration dates, and current renewal status using that same API? From reading the documentation, I understand that Apple provides the App Store Server API and the App Store Server Notifications. Is this the correct approach for receipt validation and subscription status checking? Any clarification or code example would be greatly appreciated. Thank you.

We've been pulling daily download reports (First-time downloads + Redownloads) via ONGOING requests and noticed random missing days in our data — in April alone, we are missing the 11th, 14th, 23rd, and 27th. After debugging, here's what's actually happening: Apple sometimes publishes two consecutive ONGOING instances with identical content (same processingDate → same Date in the CSV) The day after a duplicate, the CSV skips a date entirely — that data is simply never published Those missing days are gone forever. There's no way to recover them via API Does anyone know if there is a way to fix this and recover lost days?

Hello Apple Developer Support, We are encountering an App Store Connect issue with an In-App Purchase that appears to be stuck in an invalid state after the Traditional Chinese (zh-Hant) localization was rejected during review. App details: App name: [APP_NAME] Bundle ID: com.carolgames.gxb App Apple ID: [APPLE_APPLE_ID] In-App Purchase reference name: [IAP_REFERENCE_NAME] Product ID: [PRODUCT_ID] In-App Purchase type: [CONSUMABLE / NON_CONSUMABLE / etc.] Affected localization: zh-Hant Problem summary: The zh-Hant localization for this In-App Purchase was rejected during review. After the rejection, we tried to delete only the rejected localization in App Store Connect, but the operation failed with a server error. We also tried to modify and delete the same localization through the App Store Connect API, but both operations failed. As a workaround, we deleted the entire In-App Purchase. However, when we tried to recreate it using the same Product ID, App Store Connect reported that the Product ID was already in use / duplicated. This blocks us from continuing to use the original Product ID already integrated in our app and backend systems. Expected behavior: After a localization is rejected, we should be able to edit or delete that rejected localization and resubmit it. If the record is in an invalid state, we need a recovery path that preserves the existing Product ID. Request: Could you please investigate this App Store Connect state and help us recover the original In-App Purchase record or reset the broken zh-Hant localization state so that we can continue using the existing Product ID? Steps to reproduce: Create an In-App Purchase with Product ID [PRODUCT_ID]. Add zh-Hant localization and submit it for review. The zh-Hant localization is rejected. Attempt to delete the rejected localization in App Store Connect, but the operation fails with a server error. Attempt to modify or delete the same localization through the App Store Connect API, but those operations also fail. 6. Delete the entire In-App Purchase as a workaround. 7. Attempt to recreate the In-App Purchase with the same Product ID. 8. App Store Connect reports that the Product ID is already in use / duplicated. We do not currently have screenshots or preserved error payloads, but the issue is reproducible from the current App Store Connect state. Thank you.

I’m trying to manage pricing for auto-renewable subscriptions using the App Store Connect API (JWT). For In-App Purchases (non-consumable / consumable), I can: list price points set pricing using pricePointId However, for subscriptions: I can create subscription groups and subscriptions but I cannot find a clear way to: read current pricing (e.g. US price) set pricing via API I also tried using the asc-cli tool (v0.17.2), but it does not expose subscription pricing commands. Questions: Is subscription pricing accessible via the App Store Connect API? If yes, which endpoint should be used? If not, is this intentionally limited compared to IAP pricing? Any guidance or examples would be very helpful.