Dear Apple Support,
We are currently in the process of migrating from Apple Server Notifications v1 to v2. As you know, once we switch from v1 to v2 in App Store Connect, this change is irreversible. Our team needs to ensure that our backend environment, developed in Python with Django and using the app-store-server-library==1.5.0, is fully prepared to handle all possible notification types before making that final switch.
While we can receive a basic test notification from Apple, it doesn’t provide the range of data or scenarios (e.g., INITIAL_BUY, RENEWAL, GRACE_PERIOD, etc.) that our code must be able to process, store in our database, and respond to accordingly. Without comprehensive, example-rich raw notification data, we are left guessing the structure and full scope of incoming v2 notifications.
Could you please provide us with a set of raw, fully representative notification payloads for every notification type supported in v2? With these examples, we can simulate the entire lifecycle of subscription events, verify our logic, and confidently complete our migration.
Thank you very much for your assistance.
Post
Replies
Boosts
Views
Activity
I want to create a service where users can see their AppStore sales, but I then need them to provide their API-keys for me to be able to retrieve their data trough my service. But is that prohibited? Is there some other way to solve this?
This is what it says when requesting the API-key:
Request Access to the App Store Connect API
The App Store Connect API is for internal development, testing, and reporting purposes within your team only, and lets you automate key parts of your own internal workflow, including:
TestFlight. Managing beta builds of your app, testers, and groups.
Users and Access. Sending invitations for users to join your team, adjusting user permissions, and removing users.
Reporting. Downloading sales and financial reports for your app.
You may not use this App Store Connect API to provide services to any third parties or for any other use. As a reminder, you may not share authorization credentials with anyone outside your team or solicit authorization credentials from any third parties. As requests are reviewed, organization will be given first access followed by individuals.