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

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 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 ?

Hey has someone figured out how or when does a report request become inactive? Is there like a fixed time period for how long an ONGOING accessType stays active? And does the same rule apply for ONE_TIME_SNAPSHOT? Has someone managed to create multiple active reports for both accessTypes per one app? And can you have multiple inactive ones?

Hey has someone figured out how or when does a report request become inactive? Is there like a fixed time period for how long an ONGOING accessType stays active? And does the same rule apply for ONE_TIME_SNAPSHOP? Has someone managed to create multiple active reports for both accessTypes per one app? And can you have multiple inactive ones?

Hey has someone figured out how or when does a report request become inactive? Is there like a fixed time period for how long an ONGOING accessType stays active? And does the same rule apply for ONE_TIME_SNAPSHOP? Has someone managed to create multiple active reports for both accessTypes per one app? And can you have multiple inactive ones? Sadly couldn't find answers to my questions from the App Store Connect API documentation :(

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.