The App Store Connect API specification states that a customer review includes a rating, a title, a body, a reviewer nickname, a creation date, a territory and a response. Unfortunately, it does not provide information on the app version that was reviewed or whether it was edited after a response was posted (or at least when it was last updated). In order to retrieve all reviews including the app version, you first need to fetch all versions of an app, and then fetch all reviews per version. This results in a lot of unnecessary requests, particularly when there are very few to no reviews for a version. Furthermore, determining if or when a review has been updated by a customer is simply not possible via the API. As these informations are available in the App Store Connect UI for all reviews, I would appreciate it if they could be added to the API as well.

I had a personal Apple account which I used to upload apps to App Store Connect for our company. I used altool with an app-specific password, like this: xcrun altool --upload-app -u mylogin%mycompany.com -p my-app-specific-password --file MyApp.ipa --type ios --verbose Recently I was asked to convert to it a company-managed account. Once I did this, altool stopped working, with the error "Failed to determine the appleID from bundleID com.mycompany.myapp with platform IOS. Unable to generate an Apple Connect token at this time due to a general error." The complete error log is below. I tried creating a new app-specific password, but had the same result. If I deliberately use the wrong password, I get a different error: "Failed to determine the appleID from bundleID com.mycompany.myapp with platform IOS. Your Apple ID or password was entered incorrectly." So I don't think it's a password problem. I can manually upload to App Store Connect using Xcode with this same account, so it seems like it has the right permission. Any idea why altool wouldn't work? complete output

Hi, In the web portal of developer.apple.com when you create or edit a provisioning profile there is a possibility to set "Entitlements", which is I understand also called as "Template". Our project has such entitlements, like NSE Filtering or CarPlay. But in the ProfileCreateRequest https://developer.apple.com/documentation/appstoreconnectapi/profilecreaterequest there is no possibility to provide such parameter, this is why we are not able to automate our flow of provisioning profile update. Is there any workaround? Or maybe I need to fill a request to improve this API?

We have been using this API call to set the In-App Provisioning capability for 2+ years and it just recently started returning errors. To set the In-App Provisioning capability we had been using the App Store Connect API directly: curl "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities" -X POST --header "Authorization: Bearer #{appleApiToken}" --header "Content-Type: application/json" -d '{"data": {"type": "bundleIdCapabilities", "attributes": {"capabilityType": " IN_APP_PASS_PROVISIONING"}, "relationships": {"bundleId": {"data": {"id": "#{appStoreBundleIdentifier}", "type": "bundleIds"}}}}}' The IN_APP_PASS_PROVISIONING capability type is shown, by getting the bundle ID capabilities, when In-App Provisioning is set on a bundle ID: curl "https://api.appstoreconnect.apple.com/v1/bundleIds/#{appStoreBundleIdentifier}/bundleIdCapabilities" --header "Authorization: Bearer #{appleApiToken}" After manually setting the In-App Provisioning capability via the Apple Developer portal you will see the new capabilityType: {     "type" : "bundleIdCapabilities",     "id" : "##########_IN_APP_PASS_PROVISIONING",     "attributes" : {       "settings" : null,       "capabilityType" : "IN_APP_PASS_PROVISIONING"     },     "relationships" : {       "bundleId" : {         "links" : {           "self" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING/relationships/bundleId",           "related" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING/bundleId"         }       }     },     "links" : {       "self" : "https://api.appstoreconnect.apple.com/v1/bundleIdCapabilities/##########_IN_APP_PASS_PROVISIONING"     }   } The problem now is Apple has recently (within the last week) removed support for setting the IN_APP_PASS_PROVISIONING capability type via the bundleIdCapabilities API endpoint. {   "errors" : [ {     "id" : "c6644913-d1c5-4eda-9faa-7766adf25c39",     "status" : "409",     "code" : "ENTITY_ERROR.ATTRIBUTE.TYPE",     "title" : "An attribute in the provided entity has the wrong type",     "detail" : "'IN_APP_PASS_PROVISIONING' is not a valid value for the attribute 'capabilityType'. Expected one of: 'ICLOUD', 'IN_APP_PURCHASE', 'GAME_CENTER', 'PUSH_NOTIFICATIONS', 'WALLET', 'INTER_APP_AUDIO', 'MAPS', 'ASSOCIATED_DOMAINS', 'PERSONAL_VPN', 'APP_GROUPS', 'HEALTHKIT', 'HOMEKIT', 'WIRELESS_ACCESSORY_CONFIGURATION', 'APPLE_PAY', 'DATA_PROTECTION', 'SIRIKIT', 'NETWORK_EXTENSIONS', 'MULTIPATH', 'HOT_SPOT', 'NFC_TAG_READING', 'CLASSKIT', 'AUTOFILL_CREDENTIAL_PROVIDER', 'ACCESS_WIFI_INFORMATION', 'NETWORK_CUSTOM_PROTOCOL', 'COREMEDIA_HLS_LOW_LATENCY', 'SYSTEM_EXTENSION_INSTALL', 'USER_MANAGEMENT', 'APPLE_ID_AUTH'",     "source" : {       "pointer" : "/data/attributes/capabilityType"     }   } ] } How do we set the In-App Provisioning (IN_APP_PASS_PROVISIONING) capability type via the Apple API on bundle IDs that have been approved by Wallet Entitlements?

I'm experiencing an issue with the Analytics Reports API. Since last week, no data is being returned from the following endpoint: https://api.appstoreconnect.apple.com/v1/analyticsReports/r2-ac29debd-e528-406d-bdfa-fab6d4403ee2/instances The endpoint responds successfully but returns empty data for the date range where data should exist. Other report endpoints for the same app work correctly. Please investigate why this report stopped delivering data.

We are currently pulling data via the API to look various metrics, including reviews and ratings. However, I noticed the ratings only come in with associated reviews - it doesn't appear there is public access to the API for pulling all historic ratings (without associated reviews). Is this correct? Does anyone know a workaround or way to access the ratings data via API or other method?

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?

Hello everyone, I'm having trouble testing custom offer codes for my auto-renewable subscription in the Sandbox environment. I am using the modern StoreKit 2 API to display the redemption sheet: try await StoreKit.AppStore.presentOfferCodeRedeemSheet(in: windowScene) When I enter a valid custom code that I created in App Store Connect, the system sheet immediately returns the following error: "Cannot Redeem Code. The code entered is not valid. [environment: sandbox]" To be clear, I am manually typing the custom code string itself into the redemption sheet's text field, not using a one-time code link or URL. I believe my configuration is correct, and I've already spent a significant amount of time troubleshooting. Here is a list of everything I have checked and tried so far: App Store Connect Configuration: The Offer Code is marked as "Active". The parent subscription product is approved and its status is "Ready for Sale". The offer's eligibility is set correctly The start and end dates for the offer are valid. Despite all these steps, the error persists. At this point, I suspect this might be a temporary issue with the Sandbox environment itself, but I want to make sure I haven't missed any crucial configuration steps. Has anyone else encountered this issue recently? Is there anything else I should be checking? Any help would be greatly appreciated. Thank you.

I am contacting you to clarify a technical issue regarding the behavior of App Store Server Notifications (V2), as we have observed differences depending on the subscription plan. Currently, we have noticed the following behavior when a refund occurs for an auto-renewable subscription: Observed Behavior: Monthly Plan:When a refund occurs, we receive a REFUND notification, followed by an EXPIRED notification indicating the subscription has ended. Annual Plan:When a refund occurs, we receive the REFUND notification, but the expected EXPIRED notification does not arrive. Questions: Are there any differences in the conditions for sending EXPIRED notifications after a REFUND, depending on the subscription plan (monthly vs. annual)? Is the absence of the EXPIRED notification for annual plans an intended behavior by Apple, or could it be a possible issue? I would appreciate your guidance on this matter.

I know 500 means an issue on the server. But the system status page is all green and I think the App Store Connect API has a history of incorrectly returning 500 instead of 4xx statuses, e.g. here. So I'm sharing this in the hope of getting some more information. I am following the steps here: https://developer.apple.com/documentation/appstoreconnectapi/uploading-assets-to-app-store-connect My PNG data is successfully uploaded to the URL contained in the Upload Operation for the screenshot. The next step is to confirm the upload with its MD5 checksum, which fails. [15:59:27.289] DEBUG (74920): AppleUploadService: PUT https://northamerica-1.object-storage.apple.com/itmspod11-assets-massilia-200001/PurpleSource211/v4/d8/8d/4b/d88d4b7c-ef96-e3a0-bfab-b793903bf2db/taiz5B2iCIVeTQQlGZFfx4f2jMPAbVruq7JKHmykh7M_U003d-1768937158953?... [15:59:28.727] DEBUG (74920): AppleUploadService: 200 OK [15:59:33.735] DEBUG (74920): AppStoreConnectApiClient: PATCH https://api.appstoreconnect.apple.com/v1/appScreenshots/08e7802f-5a52-49a8-91c5-f4040721607a { "data": { "type": "appScreenshots", "id": "08e7802f-5a52-49a8-91c5-f4040721607a", "attributes": { "uploaded": true, "sourceFileChecksum": "714d426fc4fb39f732dca9f481c7039b" } } } [15:59:34.359] DEBUG (74920): AppStoreConnectApiClient: 500 Internal Server Error I can't see anything wrong with my request body. Has anyone else encountered something similar or is this truly an outage?

Hello, I am using the App Store Connect Finance Reports API to export monthly financial statements. API endpoint: https://api.appstoreconnect.apple.com/v1/financeReports Request parameters: reportDate: 2026-01 reportType: FINANCE_DETAIL However, the returned report shows an unexpected date range: Start Date: 09/29/2025 End Date: 11/01/2025 This does not match the requested month January 2026, and instead seems to cover a different settlement period. I would like to confirm: Is the Finance Reports API returning data based on Apple’s settlement cycle rather than the requested calendar month? How should we correctly map reportDate to the actual statement period? Is there a recommended way to reliably retrieve the financial report for a specific month (e.g. Jan 2026)? This behavior makes automated reconciliation difficult, so any clarification or guidance would be appreciated. Thank you very much for your help.

we have 80 users occur error,when use aca pay

我们仅有一个订阅组，一个用户收到了订阅续费消息，我们不知道发生了什么， 续费消息中的originTransactionId没有发生变化，但是userAccountToken却变化了，指向了另一个用户，此时旧的用户不会收到续费在哪的任何消息。 哪位技术大佬可以帮助解答问题，什么情况下会出现这样的情况

问题：一个用户升级后，苹果的通知消息中 userAccountToken 不变，但是 originTransactionId变了。此时升级前的originTransactionId还会进行周期扣款，升级后的originTransactionId也会进行周期扣款。 注意，订阅的配置是在同一个组中 哪位技术大佬可以帮助解答问题，什么情况下会出现这样的情况

Hey there, We've been using App Store Connect API to manage (create/update) Advanced App Clip Experiences via App Store Connect API. Everything has worked fine, we've been able to successfully manage hundreds of app clips but all of a sudden starting on December 15th the API started returning the following error: "id" => "1e15b36b-5347-4af0-9bab-7f6626ffec65" "status" => "409" "code" => "ENTITY_ERROR.INCLUDED.INVALID_ID" "title" => "The provided entity id is invalid" "detail" => "The provided included entity id 'EN' has invalid format" "source" => array:1 [▼ "pointer" => "/included/0/id" ] It does seem to be an API bug considering it has always worked fine and we didn't change anything on our side, the /included/0/id value has always been EN and never changed. Moreover, EN still seems to be a valid value according to the API docs and there are no changes reported of that field in the API release notes. Here's the request ID: 1e15b36b-5347-4af0-9bab-7f6626ffec65 I've tried using different values through trial and error (en, EN, EN-US, ...) and none of them worked.

When uploading an iOS IPA via App Store Connect API or altool, App Store Connect validates the IPA against the wrong existing app record, even though the IPA is correctly signed and provisioned. The exact same IPA uploads successfully via Apple Transporter, which correctly routes it to the intended app. This appears to be an App Store Connect upload-resolution issue specific to API-based delivery. Environment Account: App Store Connect (Admin access) Authentication: App Store Connect API Key (Issuer ID + Key ID) Apps in Account: com.dailyaudiobible.dabapp Apple ID: 121xxxx266 com.dailyaudiobible.dabapp2 Apple ID: 645xxxx428 iOS / SDK Details Platform: iOS Build Artifact: Single signed IPA used for all tests Target SDK: iOS 18.5 Xcode: 16.4 .NET iOS SDK: 18.5.9227 Minimum iOS Version: 18.5 Architecture: ios-arm64 Build Type: App Store distribution (Release) This SDK/Xcode combination previously worked for TestFlight uploads of this app. Expected Behavior When uploading an IPA with: CFBundleIdentifier = com.dailyaudiobible.dabapp Provisioning profile for com.dailyaudiobible.dabapp Embedded provisioning profile matching com.dailyaudiobible.dabapp App Store Connect should validate and associate the build with the dabapp app record. Actual Behavior When uploading the IPA using API-based tools, App Store Connect validates the upload against dabapp2 and rejects it with: Validation failed (409): This bundle is invalid. The bundle identifier cannot be changed from the current value, com.dailyaudiobible.dabapp2. No references to dabapp2 exist in the codebase, build configuration, or signing assets. Delivery Methods Tested (Same IPA) App Store Connect API (automation / CI) Upload accepted Validation fails Error references com.dailyaudiobible.dabapp2 altool (Apple CLI, API key authentication) Same behavior as API Same validation error altool logs confirm API key has access to multiple apps but validation resolves to the wrong app Apple Transporter (manual) Automatically detects com.dailyaudiobible.dabapp Upload succeeds Build appears correctly under the dabapp record in App Store Connect This confirms the IPA itself is valid and correctly signed. Verification Performed From the built IPA: Info.plist CFBundleIdentifier = com.dailyaudiobible.dabapp Embedded provisioning profile Application identifier resolves to com.dailyaudiobible.dabapp Provisioning profile used at build time: Explicitly configured for com.dailyaudiobible.dabapp All values are verified by extracting the IPA contents locally. Questions for Apple Engineering Why do API-based uploads (App Store Connect API / altool) resolve this IPA to the wrong existing app record, while Transporter resolves it correctly, and how can that association be corrected or reset? If this is expected behavior when multiple related apps exist under one provider, is this documented, and are there required parameters or constraints for API-based uploads in this scenario? Additional Notes This is reproducible using only Apple-provided tools and APIs. CI/CD tooling itself is not required to reproduce the issue. Manual Transporter uploads are not a viable long-term solution for automated releases. Any guidance or confirmation from App Store Connect engineering or other developers would be appreciated.

What am I missing here? 😐 Prepare all required actions Run ./.github/actions/verify-copyright Run echo "📋 Checking copyright file..." 📋 Checking copyright file... ✅ Copyright file exists at: fastlane/metadata/en-US/copyright.txt 📝 Copyright value: © 2025 Enterprise Support ✅ Copyright format valid: © 2025 Enterprise Support ✅ Copyright metadata validation passed

I am in a process to change ASSN-V2 url, However i am still receiving Subscription notifications on old URL. Changed to new URL from Appstore connect --> --> App Information. Old URL is pointing to aws lambda. New URL is pointing to a third party provider (confirmed not received notification.) Any pointers ?

Hello, I'm trying to upload an asset pack that has the same identifier as an asset pack that I've archived. I understand this isn't likely a common scenario, but I'd expect that uploading an archived Asset Pack to become un-archived. Reverting to the next newest version available for the Asset Pack. Further, this restriction is not clear that you won't be able to reuse the assetPackID on the archive asset pack alert Archive Asset Pack? Are you sure you want to archive "[NAME]" asset pack? All versions of this asset will no longer be accessible by your app. Errors: Failed to create a new background asset pack version for '[NAME]'. (-19243) operation not allowed (409) Cannot create version for an archived background asset. (ID: 2cc6499a-83fa-4bbb-bc1f-0bb67d2a873d) httpBody: { "errors" : [ { "id" : "2cc6499a-83fa-4bbb-bc1f-0bb67d2a873d", "status" : "409", "code" : "STATE_ERROR.ARCHIVED_BACKGROUND_ASSET", "title" : "operation not allowed", "detail" : "Cannot create version for an archived background asset." } ]

Hey there, I'm building a service that requires receiving accurate sales/proceeds data along with the campaign name. From reading the documentation it looks to be fairly understandable, but in practice it is not. I have been testing this for almost a week, and I never got "Detailed Report" for "App Store Purchases Detailed" analytics report. The same report for "App Downloads Detailed" is arriving normally, but not to for the purchases. I tested for two different apps where I have around 200 daily installs and 30 purchases on each. I would love to get any thoughts on this from an Apple engineer!