I was using the Download Sales and Trends Reports API (GET https://api.appstoreconnect.apple.com/v1/salesReports), but at some point, the results started not displaying properly. (The reason for this is that all the +sales values ​​aren't showing up in the CSV file.) Below, I'll show you how to use the API in Python with a screenshot. (***** elements are hidden.) If anyone knows why, please let me know.

Logging out: The platform logs people out super quickly (e.g. within like a couple of hours), it would be great to be able to stay logged in within the same day and not have to log back in every time. Latency: In general, it can be really slow to load, and sometimes pages fully load without anything on them. The team then has to refresh the page for e.g. dashboards to be shown Submission of PPO & In-app events: PPO tests and in-app events can only be submitted on the latest version, which means that you need to wait for a period when we're not having a new version of the app reviewed. If this is regularly the case, it's difficult to submit. Sometimes you then submit e.g. an in-app event, but it takes a while and the review is removed in favour of an app update. Solution: The whole thing should follow a similar process to CPPs whereby you don't need to upload to the latest version, or you should be able to select which app version you're uploading to and be able to select the latest. Rather than having to delete and build again every time. Pricing updates: The amount of time that it takes to change pricing is insane and results in a reluctance to make price changes. There are a number of ways that this could be improved: a) Don't only allow us to select prices from a drop down list. This process adds like 3 extra clicks to every single price change. Just make the prices editable (e.g you can type) in a list, Google Play Console does this very well. b) For promotions, allow us to set e.g. "20% off the default price" and then when we make pricing updates to the default price the promotional price will update automatically. Instead currently we have to go in and manually calculate 20% off every single price based on the new price and update it ourselves, it's crazy. Reporting on promotions: Currently, there is no ability to see a time series of conversions with specific promotions with configurable date ranges, you can just see the total redemptions up to a certain date. This means we're manually having to look at the number of redemptions up to a certain date and then if we wanted to see a daily breakdown we'd need to look at ever date in isolation and calculate the increase in number of redemptions.

I am planning to build a service that automatically pulls Apple reports and stores them in my database. I was able to successfully retrieve the APP_USAGE report from the Analytics API. It initially generated daily reports for a couple of days, but then the daily report generation stopped. The weekly and monthly reports continue to generate normally. I also checked the readReportRequest response, and the StoppedDueToInactivity field is returned as false. And also, when I compared the monthly reports between the API and the web console, the data does not match. Does anyone have a solution to this issue, or is there a recommended or updated approach for handling this?

I am planning to build a service that automatically pulls Apple reports and stores them in my database. I was able to successfully retrieve the APP_USAGE report from the Analytics API; however, while it initially generated daily reports for a couple of days, the daily report generation subsequently stopped. The weekly and monthly reports are generated normally. I also checked the readReportRequest response, and the StoppedDueToInactivity field is returned as false. And also, when I compared the monthly reports between the API and the web console, the data does not match. Does anyone have a solution to this issue, or is there a recommended or updated approach for handling this?

We have changed app icon a while ago, it displayed correctly on distribution page and on other pages - with an exception of analytics - https://appstoreconnect.apple.com/analytics No matter what time range is selected it still displays old icon. Can I make something with it? It's been more then a year and it's definitely not a cache issue.

Hi everyone, We’re experiencing an issue with App Store Connect → Sales & Trends (Sales) → Last 24 Hours (hourly) reporting, specifically for In-App Purchase (IAP) sales. On January 30–31, 2026, when checking Last 24 Hours sales data, we consistently see IAP sales drop to 0 starting around 18:00 UTC, as if no purchases happened after that time. However, we can confirm that IAP transactions did occur during the same time window using other validation sources (e.g., server-side logs / analytics). In App Store Connect, those hours still show 0. I did a quick search and found reports of similar behavior affecting downloads/units for some teams, but in our case downloads/units look normal in Last 24 Hours. The problem appears to be only in the IAP sales portion. Questions: Is anyone else seeing hourly gaps / 0 values for IAP around Jan 30–31, 2026 (or today)? Is this a known Sales & Trends reporting delay that eventually backfills, or an ongoing issue? If you’ve seen this before, how long did it take to normalize/backfill, and did any specific check/filter help?

Starting on 1/30/2026, we started getting an error when using Reporter to retrieve a Subscriber/Sales report from App Store Connect. Our script was working daily perfectly for a long time before this. It normally pulls the report from 1 day prior. We have been troubleshooting and cannot seem to find any issues on our end. Is this a universal issue for other users too?

The Crashes report in App Store Connect Analytics for my app is showing unexpectedly high crash rates, well over 2,000 per day (among roughly 150k active users per day). But I'm having trouble correlating this with other sources of stability reports: Firebase Crashlytics shows about 100 crashes per day over the last 90 days In the Xcode organizer, under “On-Screen Terminations” I see “Insufficient usage data available” which I take to mean very low numbers In the Xcode organizer, under "Background Terminations" it shows a little over 2 terminations per day, and well over 95% of those are "System Pressure" In the actual crash reports section of the Organizer, I have a little over 6,000 devices in the last two weeks encountering an issue that I think is 0xdead10cc, which I think would show up under Background Terminations as File Lock. As a side note, triaging these 0xdead10cc issues in the Organizer is a pain - see FB12292887. My main question here is what is included in App Store Connect's crash numbers. Do they include background terminations, especially "System Pressure"? Is there a way for me to get more information on the distribution of termination / crash types in those numbers? My understanding of System Pressure terminations is that it's when the system has to kill my app in the background to free up resources for other things, especially an app in the foreground, and it's not a "crash" properly speaking, although I might be able to make them less frequent if I reduce my memory usage. Am I incorrect in this? Notably, "System Pressure" is conspicuously not defined in the "Reducing Terminations in Your App" documentation under "Background termination reasons". https://developer.apple.com/documentation/xcode/reduce-terminations-in-your-app

I am not seeing any sales data in the app store since 3/16/2026 but there are units sold and proceeds displayed. Anyone from Apple to give an update? Any other developers seeing the same problem?

20 days passed since I released the app. According to Trends it has 30+ installs and 10 In-App purchases. When will I finally get analytics? Can't wait to see it, because I'm actively promoting my app and I wish to know the marketing performance. All that I see now in App Store Connect is this message: Other apps have no signs of this issue, I assume that the analytics is missing because the app is new. The question is "when"? :)

We are observing a discrepancy in crash data between the App Store Connect UI and the App Analytics APIs for our iOS application. For example: On March 10, App Store Connect shows approximately 2,443 crashes (average ~2K/day). However, in our analytics database (fetched via App Analytics APIs), we are seeing 10,000+ crashes for the same date. APIs Used (IDs masked): /v1/apps/{app_id}/analyticsReportRequests /v1/analyticsReportRequests/{request_id}/reports?filter[category]=APP_USAGE /v1/analyticsReports/{report_id}/instances?filter[processingDate]=YYYY-MM-DD&filter[granularity]=DAILY /v1/analyticsReportInstances/{instance_id}/segments Clarifications Required: What could be the reason for the significant difference in crash counts between App Store Connect UI and Analytics API Are there differences in how crashes are counted in: UI metrics vs raw analytics reports? Deduplication, session-level vs event-level aggregation? Is there any known aggregation rule, or filtering applied in the UI that is not reflected in the API data? Which source should be considered the accurate/authoritative count for reporting purposes? Any clarification or guidance on this discrepancy would be greatly appreciated.

Hello, After doing some research and asking AI, I am still not sure if I am correctly formatting our meta tag. Different AIs are saying conflicting things. Is this smart app banner meta tag formatted correctly so that installs will show up in app store connect analytics under the correct campaign? I want to be sure before using this in our production environment. 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?

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?

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

It looks like the method (m=) property for Reporter is being ignored, which has broken our data pipelines. If I run the command below: java -jar ././Reporter.jar p=Reporter.properties a=[acc] m=Robot.XML Sales.getReport [vendor], amContent, Detailed, Daily, 20260512, 1_2 I get the following output: Successfully downloaded AppleMusic_Content_[vendor]_20260512_V1_2.txt.gz When I should be seeing an XML output that is machine readable.

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.