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.

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.

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?