App Store Connect

Version 0.0.3

📘

Checkout the docs here for more information

Prerequisites


To generate keys, you must have an Admin account in App Store Connect. You may generate multiple API keys with any roles you choose.

Set up


To get set up with the App Store Connect Source you will need the following:

  • App Store KID
  • Issuer
  • Private Key

App Store KID

Your private key ID from App Store Connect; for example 2X9R4HXF34.

Issuer

Your issuer ID from the API Keys page in App Store Connect; for example, 57246542-96fe-1a63-e053-0824d011072a.

Private Key

You can see instructions to download your private key here.


Features


FeatureSupportNotes
BackfillBackfill will start from the selected report date
IncrementalSales and Trends Reports - SALES(new version); Sales and Trends Reports - SUBSCRIBER; Sales and Trends Reports - SUBSCRIPTION ;Sales and Trends Reports - SUBSCRIPTION EVENT
Custom backfillSales and Trends Reports - SALES(new version); Sales and Trends Reports - SUBSCRIBER; Sales and Trends Reports - SUBSCRIPTION ;Sales and Trends Reports - SUBSCRIPTION EVENT
API reliability🟢Reliable

Reports detail


⬇️ Report🔑 Incremental key🔑Primary key📄 Link to API endpoint
Sales and Trends Reports - SALESEND_DATEN/ASales and trends report
Sales and Trends Reports - SALES (new version)END_DATEN/ASales and trends report
ReviewsN/AIDReviews report
Sales and Trends Reports - SUBSCRIBERREPORT_DATEN/ASales and trends report
Sales and Trends Reports - SUBSCRIPTIONREPORT_DATEN/ASales and trends report
Sales and Trends Reports - SUBSCRIPTION EVENTREPORT_DATEN/ASales and trends report
Generate Analytics Report *N/AN/ARequest Reports
App Store Installation and Deletion Detailed (One time snapshot)N/AN/ADownload Analytics Report
App Store Installation and Deletion Detailed (Ongoing)_REPORT_PROCESSING_DATEN/ADownload Analytics Report
Analytics Report ListN/AN/ARead Report Requests
Delete/Remove Analytics Report (DESTRUCTIVE!)N/AN/ADelete a report request

Limitations


📘

Sales and Trends Reports - SALES (new version)

The report will allow you to backfill in custom periods to a maximum of 1 year back (with DAILY frequency). It then can incrementally get new data from the last END_DATE in the table to 2 days before the run day (on the day of the run last date will be 2 days before today). You will need to de-duplicate, which you can do using the KLEENE_EXTRACT_DATE

📘

Sales and Trends Reports - SUBSCRIBER / SUBSCRIPTION / SUBSCRIPTION EVENT reports

The reports will allow you to backfill in custom period to a maximum of 1 year back. It then can incrementally get new data from the last REPORT_DATE in the table to 2 days before the run day (on the day of the run last date will be 2 days before today). You will need to de-duplicate which you can do using the KLEENE_EXTRACT_DATE

📘

Sales and Trends Reports - SALES

The older report allows you to pull yearly, monthly and daily data for the sales report (with frequencies longer than DAILY, allowing you to go further back than 1 year).

Daily reports are available for 365 days, weekly reports for 52 weeks, monthly reports for 12 months, and yearly reports indefinitely.

Depending of the date you select on the Report Date setting on the Extract, the report will pull date for that year/month/week/day. Further runs on append will extract the following period of the same frequency.

📘

App Store Installation and Deletion Detailed reports & Generate Analytics Report

Generating Analytics Reports usage:

To extract data for the two App Store Installation and Deletion Detailed reports, you must first create an Analytics Report Request with App Store Connect.

This is done via the Generate Analytics Report and must be performed once per AppStore app per access type:

ONE_TIME_SNAPSHOT — provides a fixed historical snapshot

ONGOING — provides a rolling, continuously updated dataset

Each (app, accessType) combination can only be created once. If a report request already exists for a given access type, additional attempts to create it will return an error.

Once you have the report generated you can start using the App Store Installation and Deletion Detailed (One time snapshot) and App Store Installation and Deletion Detailed (Ongoing) reports, which extract the actual data, once the API is ready generating it.


📘

App Store Installation and Deletion Detailed reports incremental logic and duplicates

Incremental extraction is supported only for the App Store Installation and Deletion Detailed (Ongoing) report and is based on the _REPORT_PROCESSING_DATE column.

_REPORT_PROCESSING_DATE represents the date on which Apple processed and published a batch of analytics data. During incremental runs, only data with a newer _REPORT_PROCESSING_DATE than the last processed value is fetched.

The App Store Connect Analytics API may resend previously delivered rows or publish corrections for past event dates in later processing batches. As a result,** duplicate logical rows are expected and must be handled in a transform layer.**

The data does not include a single primary key. To deduplicate, use a composite key consisting of the event date column and all dimension columns present in the report, and keep the row with the most recent _REPORT_PROCESSING_DATE.

The App Store Installation and Deletion Detailed (One-time snapshot) report does not include _REPORT_PROCESSING_DATE and does not support incremental extraction. It returns a fixed historical dataset as generated by the App Store Connect API at the time the snapshot request was created.

Snapshot data can be combined with Ongoing report data in a transform layer to support historical backfill followed by incremental updates.


🚧

Analytics Report expiry rules

Analytics report instances are available for 35 days after they are generated, as described in Apple’s documentation: here.

ONE_TIME_SNAPSHOT

For ONE_TIME_SNAPSHOT reports, this means:

The snapshot request remains visible in the API.

However, its report instances are only downloadable for 35 days after they are generated.

If the instances expire before being extracted, they cannot be recovered.

For this reason, we strongly recommend:

  • Generate the ONE_TIME_SNAPSHOT report.
  • Extract and persist the data as soon as it becomes available.
  • Use the ONGOING report for incremental updates going forward.

ONE_TIME_SNAPSHOT should primarily be used for historical backfill.

ONGOING

Instances of ONGOING reports are subject to the same 35-day expiry rule.

However, because ONGOING reports continuously generate new instances, expiry should not cause data loss — provided that:

  • Extracts run regularly (ideally daily), and
  • Data is persisted in your data warehouse.

If extracts are not run for more than 35 days, older instances may expire, and data for those processing dates will no longer be retrievable.


🚧

Analytics report list and Deletion of reports

Over time, multiple Analytics Report Requests (ONGOING or ONE_TIME_SNAPSHOT) may exist for the same app. Older requests may no longer have usable report instances due to the 35-day expiry window. Retaining unused report requests can create confusion when selecting which request to use.

To help manage this:

Analytics Report List

The Analytics Report List report provides a list of existing Analytics Report Requests for your app (for either ONGOING or ONE_TIME_SNAPSHOT access types). This allows you to review and identify the IDs of all existing report requests.

Generate Analytics Report

When you generate a new Analytics Report Request, the details (including the request ID) are stored in your Data Warehouse. You can reference this table to confirm which request ID is currently in use. The Kleene_Extract_date metadata column indicates when the generation was triggered.

Delete / Remove Analytics Report (DESTRUCTIVE)

The Delete / Remove Analytics Report operation deletes the entire Analytics Report Request resource.

⚠️ This is a destructive operation.

Deleting a report request:

  • Permanently removes the request container.
  • Makes its associated reports and future instances inaccessible.
  • Does not restore expired instances.

Before deleting a report request, ensure:

  • No other integration depends on it.
  • You have already extracted and persisted any required data.
  • You understand that this cannot recover previously expired instances.

Recommendation

If a report request no longer contains valid instances (e.g., all instances have expired) and is not used by any integration, removing it can simplify report management and prevent accidental selection of unusable request IDs.

After deletion, you may generate a new Analytics Report Request if needed.