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.

I am looking for a way to get customer ratings without reviews via the App Store Connect API. The customerReviews resource seems to only return ratings which are accompanied by a review. Is there maybe another way I am missing?

Is there a way to view the opt-in rate via the API? I have been unsuccessful in finding one.

审核回复：Issue Description The app uses public APIs in an unapproved manner, which does not comply with guideline 2.5.1. Specifically, the app still uses the ScreenTime API to hide apps. Since there is no accurate way of predicting how an API may be modified and what effects those modifications may have, unapproved uses of public APIs in apps is not allowed. 代码我都没有怎么改，然后之前2025年都上架成功了的，现在更新一个版本后，就不让上架了，是怎么回事？

Hey everyone, I'm managing CI/CD pipelines for around 45 iOS apps across different Apple Developer accounts. One recurring pain point is blocked pipelines due to unsigned agreements. Things like the Paid Applications Agreement and the Apple Developer Program License Agreement. I built an internal dashboard to flag these before they block a release, but I'm hitting a wall with detection accuracy. Since there's no dedicated endpoint for agreement status, I'm running three probes per account and checking for 403 FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED: GET /v1/agreements GET /v1/bundleIds?filter[identifier]={bundleId}&filter[platform]=IOS GET /v1/certificates?limit=1 Case 1 : Works perfectly. Account has "Apple Developer Program License Agreement has been updated and needs to be reviewed" : All three endpoint return 403 (In this case, the step 1 is enough) # Step 1 /v1/agreements → HTTP 403 ⛔ BLOCKED # Step 2 /v1/bundleIds → HTTP 403 ⛔ BLOCKED # Step 3 /v1/certificates → HTTP 403 ⛔ BLOCKED # [Step 1 body] { "errors": [ { "id": "TXF6QUVS6OY66YVUNINVLKXZFA", "status": "403", "code": "FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED", "title": "A required agreement is missing or has expired.", "detail": "This request requires an in-effect agreement that has not been signed or has expired.", "links": { "see": "/business" } } ] } # [Step 2 body] { "errors": [ { "id": "MTDI5P37UTYQOOVJSMXCWUK42U", "status": "403", "code": "FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED", "title": "A required agreement is missing or has expired.", "detail": "This request requires an in-effect agreement that has not been signed or has expired.", "links": { "see": "/business" } } ] } # [Step 3 body] { "errors": [ { "id": "GI6EN2CMBFJIJJZM547LSW66KY", "status": "403", "code": "FORBIDDEN.REQUIRED_AGREEMENTS_MISSING_OR_EXPIRED", "title": "A required agreement is missing or has expired.", "detail": "This request requires an in-effect agreement that has not been signed or has expired.", "links": { "see": "/business" } } ] } Case 2 : Not detected. Different account, same message in App Store Connect UI. But v1/agreements endpoint return 404 while other 2 steps return 200 # Step 1 /v1/agreements → HTTP 404 ➖ 404 # Step 2 /v1/bundleIds → HTTP 200 ✅ OK # Step 3 /v1/certificates → HTTP 200 ✅ OK # [Step 1 body] { "errors": [ { "id": "37459578-8167-449c-ad22-e0ffa392df2d", "status": "404", "code": "NOT_FOUND", "title": "The specified resource does not exist", "detail": "The path provided does not match a defined resource type." } ] } # [Step 2 body] { "data": [ { "type": "bundleIds", "id": "xxx", "attributes": { "identifier": "xxx" }, "links": { "self": "https://api.appstoreconnect.apple.com/v1/bundleIds/[xxx]" } } ], "links": { "self": "https://api.appstoreconnect.apple.com/v1/bundleIds?fields%5BbundleIds%5D=identifier&filter%5Bplatform%5D=IOS&filter%5Bidentifier%5D=[xxx]&limit=1" }, "meta": { "paging": { "total": 1, "limit": 1 } } } # [Step 3 body] { "data": [ { "type": "certificates", "id": "xxx", "attributes": { "serialNumber": "xxx", "expirationDate": "2026-07-03T04:47:09.000+00:00", "certificateType": "DISTRIBUTION" }, "links": { "self": "https://api.appstoreconnect.apple.com/v1/certificates/[xxx]" } } ], "links": { "self": "https://api.appstoreconnect.apple.com/v1/certificates?fields%5Bcertificates%5D=serialNumber%2CcertificateType%2CexpirationDate&limit=1", "next": "https://api.appstoreconnect.apple.com/v1/certificates?fields%5Bcertificates%5D=serialNumber%2CcertificateType%2CexpirationDate&cursor=[xxx]&limit=1" }, "meta": { "paging": { "total": 4, "limit": 1 } } } Same agreement type, same UI warning, completely different API behaviour. My best guess is Apple enforces the agreement deadline progressively. The 403 gate only kicks in once the deadline is crossed or the account reaches a certain state, while the UI warning shows much earlier. What I'm looking for, Is there a supported API endpoint that reflects pending agreement status regardless of enforcement state? Or is the 403 gate genuinely the only signal available and some pending agreements just won't show up until Apple enforces them? Happy to hear "there's no API for this" if that's the reality. Just want to make sure I'm not missing something before I accept that limitation. Thanks.

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?

Hello Apple Developer Community, We are currently facing an authentication issue when calling the App Store Server API for subscription validation. Despite following Apple’s documentation and verifying all credentials, we consistently receive a NOT_AUTHORIZED error response. GET https://api.storekit-sandbox.itunes.apple.com/inApps/v1/transactions/appTransactions/{transactionId} Environment: Sandbox and Production (both tested, same result) Our Setup: Key ID: {Your Key ID} Issuer ID: {Your Issuer ID} Bundle ID: {Your Bundle ID} JWT Header: { "alg": "ES256", "kid": "" } JWT Payload: { "iss": "", "iat": , "exp": <timestamp + 5 minutes>, "aud": "appstoreconnect-v1", "bid": "" } Authorization Header: Authorization: Bearer Troubleshooting Steps Already Taken: Verified that .p8 key, Key ID, Issuer ID, and Bundle ID are all correctly configured and match the App Store Connect details. Confirmed that the system clock is accurate (UTC). Used appropriate endpoint (sandbox or production) based on environment. Ensured that the JWT is short-lived (under 5 minutes). Added the “Bearer” prefix correctly in the header. Tested JWT generations using Python. Issue: All requests return: { "errorCode": "NOT_AUTHORIZED" } Questions: Are there any additional claims or headers required for the subscriptions endpoint? Are there specific permissions or roles needed for the API key in App Store Connect? Is there a way to get more detailed logs or diagnostics for this NOT_AUTHORIZED response? Does the App Store Server API require a different aud or bid structure for certain endpoints? We already contacted Apple Developer Support, but they suggested posting here for engineering-level guidance. Any insight or examples of a working JWT + request for this endpoint would be greatly appreciated.

Hi, I can't generate new key in the App Store connect dashboard. I'm receiving this as error. { "errors" : [ { "id" : "59e466f3-70aa-4798-b183-8a4903a7c2cc", "status" : "403", "code" : "FORBIDDEN_ERROR.PLA_NOT_VALID", "title" : "Operation is forbidden because of PLA status.", "detail" : "" } ] } I'm the account owner and I accepted all the policy agreements in both apple developper dashboard and app connect dashboard. what's goin on?

Hi everyone, I am currently working on automating the renewal process for our managed certificates using the App Store Connect API. However, I've encountered an issue where certificates of the "Apple Push Service" type cannot be retrieved or created. After reviewing the documentation on CertificateType, it seems there is no corresponding type for Push Service certificates. https://developer.apple.com/documentation/appstoreconnectapi/certificatetype Is there any other way or a workaround to obtain or manage these certificates programmatically? Any advice would be greatly appreciated.

Hello everyone, I’m running into a situation in App Store Connect that appears to be a backend lock related to an approved version, and I’m looking for confirmation or similar experiences. Context: App had version 1.2.6 Version progressed to Pending Developer Release Before releasing to users, I chose Developer Reject I then edited the version number (to 1.2.7) Current State / Issue: After this, App Store Connect is effectively blocked: ❌ Cannot associate any builds to the version ❌ Uploading a build with the same version and higher build number does not help ❌ Cannot create a fresh version (no “+ Version” button is visible) ❌ App Store Connect API returns: ENTITY_ERROR.RELATIONSHIP.INVALID ❌ Remove Version / Delete Version is not available Even attempting brand‑new version numbers does not work. It looks like App Store Connect still considers the previously approved Pending Developer Release version to be active and locked internally. What I understand so far From my understanding: Once a version reaches Pending Developer Release, the appStoreVersion record becomes finalized Editing the version number does not truly create a new version Developer rejection does not unlock the version–build relationship Only one approved / pending version is allowed per app This seems to leave the app in a state where no new versions can be created without backend intervention. Question Can anyone confirm: That once a version reaches Pending Developer Release, it can only be reset or removed by App Store Connect Support, and That there is no self‑service workaround (UI, API, CI, or Transporter) to recover from this state? If anyone has gone through this and successfully had Apple reset the appStoreVersion record, I’d appreciate confirmation or tips on getting it routed correctly. Thanks in advance.

We regularly submit builds, manage provisioning profiles, and query build statuses for a large number of applications across multiple store accounts. We rely on automated tooling (Fastlane / App Store Connect API) to manage this pipeline efficiently. Recently, we have been experiencing HTTP 5xx errors when making requests to Apple's APIs (App Store Connect, Spaceship). We believe these failures are caused by rate limiting applied to our outbound IP addresses, as the errors correlate with periods of higher submission activity. We have already taken steps on our side to mitigate the issue - including distributing requests across multiple external IP addresses - but we continue to encounter these errors during peak release periods, which delays application delivery to our clients and their end users.

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.

I'm unexpectedly getting 403 status codes when calling the perfPowerMetrics APIs for any arbitrary app on my account. This worked last week, it is not working now. I have since revoked keys and recreated admin and developer keys--no luck, still getting 403. I've been working with the analytics APIs lately so I don't know exactly when the power and performance API stopped working. I've narrowed it down to something related to the token scope. When I have a scope on this endpoint of "GET /v1/apps/1234567890/perfPowerMetrics" it is rejected -- but the docs say I can create a token and reduce its scope like this. When I remove the scope and let the token be unbounded, the API call returns a valid response. FB22313063 - App Store Connect API: Fetching xcode metrics with an admin key generated token results in a 403 unexpectedly