To receive server notifications from the App Store, follow the instructions in Enabling App Store Server Notifications. If your server doesn’t receive any notifications, check your server logs for any incoming web request issues, and confirm that your server supports the Transport Layer Security (TLS) 1.2 protocol or later. If you implement version 2 of App Store Server Notifications, call the Get Notification History endpoint. If there is an issue sending a notification, the endpoint returns the error the App Store received from your server. If your issue persists, submit a Feedback Assistant report with the following information: The bundleId or appAppleId of your app The date and time your issue occurred The raw HTTP body of your notification The affected transactionId(s) if applicable The version of App Store Server Notifications (i.e., Version 1 or Version 2) The environment (i.e., Production or Sandbox) To submit the report, perform these steps: Log into Feedback Assistant. Click on the Compose icon to create a new report. Select the Developer Tools & Resources topic. In the sheet that appears: Enter a title for your report. Select “App Store Server Notifications” from the “Which area are you seeing an issue with?” pop-up menu. Select “Incorrect/Unexpected Behavior” from the “What type of feedback are you reporting?” pop-up menu. Enter a description of your issue. Add the information gathered above to the sheet. Submit your report. After filing your report, please respond in your existing Developer Forums post with the Feedback Assistant ID. Use your Feedback Assistant ID to check for updates or resolutions. For more information, see Understanding feedback status.

App Store Server Notification returns successful purchase while customer's payment remains Pending We have encountered an edge case with a Non-Renewing Subscription and would appreciate clarification on the expected developer behavior. Steps to reproduce User initiates an in-app purchase using a credit card. The purchase succeeds in the app. Our backend receives an App Store Server Notification V2 (ONE_TIME_CHARGE). We successfully verify the signed JWS transaction. The same transaction is also returned by the App Store Server API. Based on the verified transaction, we grant the user's entitlement. However, on the customer's Apple account: The purchase is shown as Pending in Purchase History / Report a Problem. The customer reports that their credit card has not yet been charged. Question From a developer's perspective, should entitlement be granted immediately after receiving a valid App Store Server Notification and successfully verifying the transaction, even if the customer's purchase is still shown as Pending? Is there any App Store Server API or transaction field that indicates the payment has not yet been settled, allowing developers to delay granting entitlement until the payment is finalized? Or is the expected implementation to grant entitlement upon successful transaction verification and revoke it only if Apple later sends a refund notification? Any clarification on the expected workflow would be greatly appreciated. Thanks in advance. :)

Hello, I’m experiencing an issue with App Store Server Notifications Version 2 in the sandbox environment. Initially, an old sandbox callback URL was configured. I then replaced it with a new callback URL in App Store Connect. The new URL was saved successfully, but newly created sandbox TEST notifications continued to be sent to the old URL. To investigate further, I removed both the production and sandbox callback URLs completely. App Store Connect showed both fields as empty, and the App Store Connect API returned null for the corresponding URL attributes. However, newly created sandbox TEST notifications were still sent to the same old URL. I later used the “Modify an App” API to configure the new production and sandbox callback URLs. The PATCH request returned HTTP 200, and a subsequent GET request confirmed the new URLs and Version 2 settings. Despite this, new sandbox TEST notifications continued to use the old hostname in the HTTP Host header. I confirmed that these are new notifications, not retries: Every test returns a new testNotificationToken. The notificationUUID matches the UUID in that new testNotificationToken. The new callback URL is publicly accessible over HTTPS. The new URL returns HTTP 200 and doesn’t redirect to the old URL. The behavior is therefore: Configure a new URL → notifications still go to the old URL. Remove all configured URLs → notifications still go to the old URL. Update the URLs through the App Store Connect API → notifications still go to the old URL. It appears that the notification delivery service is using a stale callback configuration that isn’t synchronized with App Store Connect. Is there a separate cache or routing configuration for App Store Server Notifications? Is there a way to force the effective callback URL to refresh? Thank you.

Since we configured App Store Server Notifications V2 on 15 October 2026, every notification for our app is recorded as TIMED_OUT, with the attemptDate equal to the signedDate (same second), and no HTTP request ever reaches our server. 35 Sandbox notifications (TEST, SUBSCRIBED, DID_RENEW, EXPIRED): one attempt each, TIMED_OUT. 2 Production TEST notifications: retried 5–6 times over a week, all TIMED_OUT. Our endpoint is public, TLS 1.3, valid certificate, answers in < 400 ms, and processes the signedPayload correctly when we POST it ourselves. Today we pointed the Sandbox URL to a webhook.site URL and requested a test notification: TIMED_OUT within 10 s, nothing received on webhook.site either. The app (com.virginactive.revolution, appAppleId 1620160868) was transferred to our current developer account on 2 October 2026; notifications have never been delivered under the new team, so we suspect a server-side state issue after the transfer. Latest test tokens: Sandbox: be12b40b-19a7-4723-aebf-764db83b4690_1793289992274 (29 Oct 2026 16:06 UTC) Production: 80597167-2939-4cc9-a43c-2c3c29c6a161_1792741270174 (23 Oct 2026 07:41 UTC) Feedback Assistant: FB25363489 Is there anything on our side that could make the App Store server fail before attempting the connection, or does this need to be fixed on Apple's side?

Does TestFlight's sandbox resolves storefront differently from production — because if it does, my production launch will be unaffected and this is a testing artefact. Right now, the storefront always resolves as US and fetches USD pricing, even though in my AppStoreConnect, availability and pricing country is restricted to India alone, and ideally the fetch to my subscription page shoul dbe in Indian Rupee. Any observations, any one please?

We use Apple's official App Store Server Library for Node.js, version 3.1.0. Our latest Production Get Notification History check, on 24 October 2026 at 15:21 UTC, returned HTTP 401 with an empty response body. The request ran from our deployed backend. We verified the ES256 signature, JWT claims, 300-second token lifetime, Authorization header and system clock alignment. On 23 October, notification-history requests using the same JWT and server environment returned: Sandbox: HTTP 200 Production: HTTP 401 A separate Production Request a Test Notification also returned 401; no test notification token was issued. The latest check was only a history query, not another TEST request. The account owner confirmed that the existing In-App Purchase key is Active. Our first app version remains PREPARE_FOR_SUBMISSION and has never been publicly released. Separate Production and Sandbox notification URLs are saved with Version 2 selected. An Apple App Store Commerce Engineer described a first-production-release prerequisite in this discussion: https://developer.apple.com/forums/thread/806452 Does that prerequisite apply specifically to both Get Notification History and Request a Test Notification? Neither request uses a transaction ID. If these endpoints should authenticate before the first release, which additional app-specific authorization prerequisite or non-sensitive diagnostics should we check? Apple request IDs can be provided privately through an appropriate Apple support channel if requested.

Our approved app is held at Pending Developer Release because the production App Store Server API cannot find our notification URL, even though the Production Server URL is saved in App Store Connect. The failure has been constant since August. On October 20 we ran two tests that isolate it, and we would appreciate someone from App Store Server engineering checking the request UUIDs below. What works Sandbox Request a Test Notification, same In-App Purchase key, same bundle ID, same URL string as Production: HTTP 200, token issued, Get Test Notification Status reports sendAttemptResult SUCCESS 280 ms later. 2026-10-20 16:31:13 UTC · request UUID ad1708d2-8536-4204-9a7b-32ded5800d48 · correlation key VULQRUUFGZBAJGT3GLPNLAANJA Production Get Notification History, same key: HTTP 200 (0 records, app not yet released). 2026-10-20 16:40:08 UTC · request UUID 7aedd431-fcf1-b104-42cd-17cc599425e4 · correlation key PLW5IMP46GYQIQWNC7GFTFBF4Q What fails Production Request a Test Notification (both api.storekit.itunes.apple.com and api.storekit.apple.com): HTTP 404, errorCode 4040007, "No App Store Server Notification URL found for provided app." No testNotificationToken is issued, so Apple never contacts our endpoint. Most recent: 2026-09-30 11:25 UTC · request UUID 22a1e218-4cdc-3577-9e18-3e25caf64052 · correlation key EKQ6EGCM3Q2XPHQYHYS4V5SAKI Earlier: f0cf352f-828e-fd40-8c14-2000fb8181e3 (Sept 23), 74a8bbbd-cd43-a18b-c4ac-bba619232d1d (Sept 14), 412d6c9f-511c-4402-ba18-d33fcda1b916 and 4f88fc30-3a4c-b7da-5d67c2f88570 (Sept 4, two different keys) Already done Production Server URL verified as saved in App Store Connect; removed, saved, re-added, waited, retested. No change. Reproduced with Apple's App Store Server Library (Swift) and with a minimal client. Feedback filed: FB24641446. Developer Support escalated the case to engineering on September 18; no engineering response yet. The question In thread 806452 an App Store Commerce Engineer wrote that production API access is unlocked once an app has a release in production. Our production history call succeeds for an unreleased app, so we cannot tell from outside whether the notification URL lookup behind /inApps/v1/notifications/test is gated on first release. If it is, we will release today and retest; a one-line confirmation would end a seven-week hold. If it is not, the production notification URL record for this app appears to be missing or unreadable, and we would ask that it be inspected and rebuilt. Happy to run a fresh reproduction in any time window and post the UUID. App Apple ID 6793806173, bundle com.haullynx.app.

Many of my purchases are encountering an issue when using a promotional offer (with a promo offer signature included). On the client side, everything works properly, and the purchase triggers the .success() callback. However, there are no updates in either the transaction/renewal info or via webhooks. According to the documentation, at least one of these server notifications should be triggered: OFFER_REDEEMED or SUBSCRIBED/RESUBSCRIBED. My server did not receive any signals. Furthermore, when I fetched the subscription status using the App Store Server API, the offer identifier did not appear in either the renewal info or the transaction info.

I team i am getting below error Unable to Purchase This item is currently not available in your country/region.

We are implementing regional age-assurance checks for an iPhone app that supports iOS 17 and later. It is a paid toddler app with no backend, app accounts, ads, in-app purchases, messaging or shared user content. All content is suitable for young children. Optional family voice recordings remain on the device. We plan to request Declared Age Range when Apple's regulatory signals require it, process the response locally, and avoid logging, storing or transmitting age data. We are seeking supported technical behavior, rather than legal advice or preapproval: What supported API or platform guarantee establishes that initial download/purchase parental consent was obtained? The age-range response does not appear to expose a separate initial-consent status. Apple's age-assurance Q&A says the platform prevents launching an app after a parent revokes consent. The implementation guidance also describes RESCIND_CONSENT through App Store Server Notifications. For an app with no backend or remotely accessible service, can local access rely on the platform's launch blocking, or is a notification server still required? If a server is required, what local enforcement behavior should it drive? What is the supported behavior for offline reopening and unavailable or network-error results, particularly on older supported iOS versions where the regulatory APIs are unavailable? Does platform enforcement also cover an app already running when consent is revoked, and how should an offline app handle that transition? Documentation or a sample showing this entirely local case would be helpful.

Does the App Store send a CONSUMPTION_REQUEST App Store Server Notification when a customer requests a refund for a non-renewing subscription? The documentation is inconsistent: the notificationType page lists only 'a consumable In-App Purchase or auto-renewable subscription', beginRefundRequest(in:) mentions only consumables, but the Send Consumption Information endpoint states it applies to 'any product type (consumable, non-consumable, non-renewing subscription, or auto-renewable subscription)'. Which is correct for a non-renewing subscription sold in the Saudi Arabia storefront?

We handle App Store Server Notifications V2 for an auto-renewable subscription. When we receive REFUND for the current period, we revoke the customer's access. We now want to reinstate access on REFUND_REVERSED, as the documentation says: "If your app revoked content or services as a result of the related refund, it needs to reinstate them." Before reinstating, our server verifies the transaction in signedTransactionInfo and rejects it if revocationDate is present or expiresDate is in the past. We'd like to confirm a few behaviors so that the reinstatement doesn't get rejected by our own checks: In a REFUND_REVERSED notification, does the signedTransactionInfo still contain revocationDate (and revocationReason), or are they removed? Likewise, after the reversal, does Get Transaction Info / Get All Subscription Statuses return the transaction without revocationDate? An App Store Commerce Engineer explained in thread/757119 that when a customer requests a refund, the subscription's auto-renew status is set to false. Does this apply to every refund path (for example, refunds initiated by Apple or via chargebacks), or only to refunds requested by the customer? After REFUND_REVERSED, does the auto-renew status stay off, or can it be turned back on automatically? If it stays off, is the customer expected to re-enable auto-renew themselves? We have seen reports that REFUND_REVERSED can arrive weeks after REFUND, even when expiresDate has already passed. In that case, is it correct to reinstate access only up to the original expiresDate (i.e. nothing to reinstate if it has already passed)? Thank you.

For our app, we saved a sandbox App Store Server Notifications URL with V2 enabled and independently read the configuration back. A subsequent test-notification request returned HTTP 404 / 4040007. An authenticated sandbox notification-history request shortly beforehand returned HTTP 200. We restored the original settings after collecting diagnostics. The recorded failure is covered by Feedback Assistant report FB24885397. What could explain this discrepancy, and what additional diagnostics would help Apple investigate?

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (https://developer.apple.com/forums/thread/774053) and a DTS support request on the same topic, I am posting this issue with the Feedback Assistant ID requested there: FB24820430. Summary: This is a content anomaly in Apple-signed App Store Server payloads, not a notification delivery problem — our server receives and verifies every notification; the defect is in the field values themselves. For a stable subset of subscription families, purchaseDate in JWSTransactionDecodedPayload is consistently ~8 hours later than the signedDate of the very same JWS — a purchase recorded as happening after the signed document reporting it existed. Reproducible field comparison inside one and the same Apple-signed JWS: Field relation Affected transactions Unaffected (control) transactions purchaseDate − signedDate +7h54m … +7h59m (never ≤ 0) ≈ 0 (seconds) Webhook arrival at our server ≈ signedDate (seconds to minutes), never ≈ purchaseDate ≈ signedDate originalPurchaseDate carries the same ~8h shift (renewals inherit it) no shift expiresDate − purchaseDate exactly one subscription period exactly one subscription period expiresDate − signedDate period + ~8h period All fields are documented as "UNIX time, in milliseconds". Our iOS client passes StoreKit 2 Transaction.purchaseDate through unmodified; our backend stores the epoch-millisecond values verbatim as UTC with no timezone conversion. These payloads are generated and signed by Apple infrastructure. Scale (production, as of 2026-09-14): ≈710 subscription families (distinct originalTransactionId lineages), ≈2,700 transactions — roughly three quarters of all families with renewals. Affected purchases span early March 2026 to present, ~30–45 new affected transactions per day. Observed across US, PH, ID and GB storefronts and across app build versions. Sandbox is unaffected. Our interpretation (inference, not confirmed): the offset varies between 7h54m and 7h59m rather than being exactly 8h, consistent with a local wall-clock time in a UTC+8 environment having been encoded as if it were UTC when the original transaction record was created, then inherited by all renewals of that family. Questions for Apple engineers: Is this a known issue in App Store Server data, and is there a reference we can track? What conditions cause a family's purchaseDate to be recorded this way (storefronts/regions, purchase channels, offer types, original-receipt formats)? When purchaseDate and signedDate disagree, which field is authoritative for "when the customer was charged"? The public documentation defines each field only as "UNIX time, in milliseconds" and does not define its relationship. Is remediation planned on Apple's side, or what is the recommended way to obtain the true charge time? Evidence: A focused sample project (a ~85-line Swift tool plus four unmodified signedTransactionInfo JWS samples — three affected families and one unaffected control, each carrying Apple's x5c certificate chain) is included in Feedback Assistant report FB24820430, together with the raw HTTP notification bodies for an affected and a control notification, exactly as delivered to our endpoint. Thank you.

Hello Apple Developer Forums, We are unable to authorize the Production App Store Server API Request a Test Notification endpoint. Environment: Production API: Request a Test Notification Library: Apple App Store Server Library for Java 5.2.0 Client: AppStoreServerAPIClient Result: HTTP 401 Unauthorized before a testNotificationToken is returned. We have verified the following: The key is an active In-App Purchase key created in App Store Connect under Users and Access > Integrations > In-App Purchase. The production server uses the matching .p8 private key, Key ID, Issuer ID, and bundle ID. The bundle ID is com.ansio.serviceproof.ios. The server clock is NTP-synchronized. The request uses the official Apple Java Server Library rather than a manually generated JWT. We rotated the production In-App Purchase key once and received the same 401 result. The notification URL is configured for the Production environment, uses HTTPS, and is reachable. Sandbox uses an independent key and notification configuration. We intentionally do not include the private key, JWT, Key ID, or Issuer ID publicly. According to the documentation, HTTP 401 means the JWT is invalid. Since the official library creates the JWT and the active In-App Purchase key configuration has been verified, could Apple clarify: Is any additional App Store Connect role, agreement, team activation, or entitlement required for a Production In-App Purchase key to authorize App Store Server API requests? Is there a known propagation or authorization issue that can cause a newly created active In-App Purchase key to return 401? What non-sensitive diagnostic details can help distinguish a JWT construction issue from a team-level authorization issue? Thank you.

Following the guidance in the locked thread "Reporting your App Store Server Notifications issue" (thread 774053), Feedback ID: FB24877994. Apple Developer Support case 102971044266 is open in parallel. Summary On our account no auto-renewable subscription renewal has ever succeeded, on either of our two products, while every customer-present initial purchase succeeds. In the last 48 hours 4 of 4 free trials that reached their renewal date with auto-renew ON failed with expirationIntent 2, in four countries (PK, GB, NL, US). What we observe Yearly product with a 7-day free introductory offer (all 175 territories, offerMode FREE_TRIAL, ONE_WEEK, 1 period). Monthly product with no offer. For each of the four, GET /inApps/v1/subscriptions/{originalTransactionId} returns status 3, and the renewal info has autoRenewStatus 1, expirationIntent 2, isInBillingRetryPeriod true, the correct renewalPrice and currency, no priceIncreaseStatus. Environment Production, inAppOwnershipType PURCHASED. The DID_FAIL_TO_RENEW notification (no subtype; billing grace period not enabled) arrives at the expiry time in each case. App Store Connect subscription events from 2026-08-01 to 2026-09-20: 18 free trial starts, 6 full-price starts, 4 voluntary churns from free trial, 4 from full price, 3 "Billing retry from free trial", 1 "Involuntary churn from full price", and no renewal event of any kind. So 5 of 5 unattended renewal charges ever attempted have failed, across two products and five countries, while the 6 paid monthly purchases in the same window (TR, FR, AU, MN, US) were charged normally at purchase time. The customers are in their own storefront countries (device time zones match), and none of the four cancelled. What we have verified Both products Approved, 175 price rows each, no scheduled or preserved prices; Paid Applications Agreement, Free Apps Agreement, banking, tax forms and both compliance items (DSA, MRDP) all show Active with nothing pending in App Store Connect > Business; our servers call no App Store Server API endpoint that modifies a subscription. Thread 847338 (posted today) describes every renewal on an account failing after an agreement issue, with expirationIntent 5. Ours is expirationIntent 2 and our agreements show Active, but the shape is the same: every renewal, no purchase affected. Questions for Apple engineers Is there any account, agreement or product condition that causes renewal charges to fail with expirationIntent 2 while initial purchases succeed? Is anything more than expirationIntent 2 available about these four renewals? The four original transaction IDs are in FB24877994. Is there a known issue affecting free-trial-to-paid renewals around 19 to 21 September 2026? Thank you.

Am same facing Storekit issue 0 product returns in Product identifier Array. Even i test on device it returns invalid product identifier due to 0 product array. Issue Description Step 1 Create a new Auto-Renewable Subscription from the App Information page in App Store Connect. Step 2 Complete all the required fields for the Auto-Renewable Subscription and click the "Save" button. Expected Result After saving, the subscription status should change from "Prepare for Submission" to "Ready to Submit". Actual Result The subscription status remains "Prepare for Submission" and does not change to "Ready to Submit", even though all required information has been completed and the subscription has been saved. I am currently facing a critical issue while creating an Auto-Renewable Subscription in "App Store Connect". I have already completed all the required subscription details. However, whenever I click the "Save" button, the subscription status does not change from "Prepare for Submission" to "Ready to Submit", as expected. Because the subscription never reaches the "Ready to Submit" state, every purchase attempt in the Sandbox environment fails with the following error: SKErrorDomain Code = 3 "Invalid Product Identifier" To troubleshoot the issue, I have already: Created multiple new Product Identifiers, but every identifier is reported as "invalid" in the Sandbox environment. Verified that my "Banking, Tax, and Paid Applications Agreement" is complete and active. Confirmed that all required fields for the Auto-Renewable Subscription have been filled in before saving. Since I am unable to submit the subscription for review and all Product Identifiers remain invalid, I believe there may be an issue with my App Store Connect configuration or account. I would appreciate it if you could investigate this issue and help resolve it as soon as possible, as it is currently blocking the implementation and testing of in-app purchases.

We are facing an issue with push notifications on our iOS production application and would appreciate guidance. Issue Summary Push notifications were working correctly previously but stopped working around two weeks ago. We use Firebase Cloud Messaging (FCM) for push notifications, which delivers notifications to our iOS application through APNs. The issue appears to be related to existing FCM tokens. Existing FCM Token We have an FCM token already stored in our production backend database. When we try to send a notification using this token: Our backend sometimes receives the following response: { "error": { "code": 404, "message": "NotRegistered", "status": "NOT_FOUND", "details": [ { "@type": "type.googleapis.com/google.firebase.fcm.v1.FcmError", "errorCode": "UNREGISTERED" } ] } } In some cases, the API request appears successful, but the notification is still not received on the iPhone. We also copied the exact same existing token and tested it directly using Firebase Console → Send test message. The notification was not received on the device. Newly Generated / Retrieved FCM Token We then generated/retrieved the FCM token again from the same application and tested it directly from Firebase Console. Using the newly retrieved token: The notification was successfully received on the same iPhone. This means the following behaviour is observed: Existing FCM Token ↓ Backend may return 404 UNREGISTERED OR Firebase may accept the send request ↓ Notification not received But after retrieving the token again: FCM Token Retrieved Again ↓ Firebase Console Test ↓ Notification received successfully Client-Side Configuration We have confirmed the following: APNs device token is successfully generated. FCM registration token is successfully generated. Notification permission is granted. The application is connected to the correct Firebase project. FirebaseAppDelegateProxyEnabled is set to NO. Since Firebase method swizzling is disabled, we manually assign the APNs token to Firebase Messaging. Our APNs registration code is: func application( _ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data ) { print("*** APNS Device Token: ", deviceToken) Messaging.messaging().apnsToken = deviceToken Messaging.messaging().subscribe(toTopic: "testing_new_events") { error in if let error = error { print("*** Failed to subscribe: \(error.localizedDescription)") } else { print("*** Subscribed to topic successfully") } } } Main Question About the 404 UNREGISTERED Response One part of this behaviour is particularly confusing to us. If Firebase returns: 404 UNREGISTERED NotRegistered for a particular FCM token, we would expect that token to be invalid and that the application should receive or generate a completely new FCM registration token. However, when we retrieve the FCM token again from the application, Firebase may return the same token value again. Our question is: If Firebase considers an FCM token unregistered and returns 404 UNREGISTERED when sending a notification, why can Messaging.messaging().token() or the token callback still return the same token again instead of generating a new token? For example: Token A stored in backend ↓ Backend sends notification ↓ FCM returns 404 UNREGISTERED ↓ App retrieves FCM token again ↓ Firebase returns Token A again We would like to understand whether this is expected behaviour. Specifically: Does UNREGISTERED always mean that the locally cached FCM token should immediately be replaced with a new token? If not, why can the same FCM token still be returned to the application after Firebase returns UNREGISTERED for it? Is there a delay between Firebase invalidating a registration for sending and the client generating a replacement token? Is there a recommended way to force Firebase Messaging to refresh or re-register an FCM token after receiving UNREGISTERED? Could the token be cached locally even though its server-side registration is no longer valid? Additional Questions We would also appreciate guidance on the following: Is it possible for an existing FCM token to become stale or no longer usable for notification delivery without immediately returning an UNREGISTERED error for every send attempt? Can Firebase accept a message for an existing token and return a successful response, while the notification is never delivered to the device? On iOS, could the relationship between an existing FCM token and its APNs token become invalid or stale, while the application still returns the same FCM token? Is there any APNs-side reason why an old FCM token would stop receiving notifications while a newly generated/retrieved token on the same device receives notifications successfully? What is the recommended client-side and backend-side handling after receiving a 404 UNREGISTERED response? Should we immediately remove the token from our database and wait for the application to register a new token? Our main concern is understanding why an FCM token can receive a 404 UNREGISTERED response during sending, but the application can still return the same token when we attempt to retrieve it again. Any guidance on whether this behaviour is expected, particularly regarding the interaction between FCM token registration and APNs on iOS, would be greatly appreciated.

I am using app-store-server-library-java:5.2.0. Following the official guide video, I downloaded and configured all required credentials, including the Key ID, Issuer ID, private key (.p8 file), and Bundle ID. However, when I try to send a test notification in the Sandbox environment, the request consistently returns a 401 Unauthorized error without any additional error message or details. One difference from the guide is how I handle the private key file. The guide reads the .p8 file directly from a file path on the server. In my environment, I cannot store external files on the server, so I Base64-encode the contents of the .p8 file, store it as an environment variable, and then decode it back to its original content before initializing the App Store Server API client. As far as I can tell, the decoded content matches the original key file exactly, but I am wondering whether this approach could cause any issues with authentication or JWT generation. Are there any additional prerequisites, permissions, agreements, or configuration steps that must be completed before this feature can be used? I have spent a significant amount of time troubleshooting this issue, but I have been unable to identify the root cause from the available documentation or error responses. Any guidance or suggestions would be greatly appreciated. Thank you for your help. Additional information: Library: app-store-server-library-java 5.2.0 Environment: Sandbox Credentials configured: Key ID, Issuer ID, Bundle ID, Private Key (.p8) Private key handling: Base64 encoded in environment variables, then decoded before client initialization Result: HTTP 401 Unauthorized with no response body or error details

Filed as FB24069273. Sandbox POST /inApps/v1/notifications/test consistently returns 404 {"errorCode":4040007} for our app (Apple ID 6765662617), although GET /v1/apps via the App Store Connect API confirms both subscriptionStatusUrl and subscriptionStatusUrlForSandbox are set (V2). With the same JWT, sandbox POST /inApps/v1/notifications/history returns 200 with an empty history — so the key and app resolve correctly. No organic sandbox notifications have ever been delivered, despite active TestFlight sandbox subscription activity. Exhausted remediations (4040007 persists after each, with 30-60+ minute waits): Re-saving the URLs in the App Store Connect UI (two locales) Deleting and re-adding the Sandbox URL PATCH /v1/apps setting the sandbox URL + version V2 twice, with two different valid endpoints (verified by GET each time) Removing the Sandbox URL entirely to rely on the documented Production fallback Deleting BOTH URLs, waiting a full hour, and re-creating them from scratch Testing with both an App Store Connect team key and a freshly generated In-App Purchase key — identical results Endpoints are publicly reachable (HTTPS, TLS 1.2+, port 443). Production App Store Server API returns 401, which we understand is expected for an app not yet released. This looks like a desync between App Store Connect metadata and the notification delivery registry consulted by the test-notification endpoint. Any help would be appreciated.

Environment: Production. Bundle ID: com.filmixpro.filmix. (Team ID / notification URL available privately or via Feedback Assistant.) We extended the renewal date of 3 auto-renewable subscriptions on 2026-02-28 using the Extend Subscription Renewal Date API, and received the matching RENEWAL_EXTENDED notifications. After the extended period ended, auto-renewal failed and all 3 are now in billing retry: Get All Subscription Statuses returns status=3 with expirationIntent=2 (billing error), isInBillingRetryPeriod=true, and no grace period. However, Get Notification History (production, last 180 days, filtered by transactionId) returns ONLY the RENEWAL_EXTENDED notification for each — there is no DID_FAIL_TO_RENEW (nor EXPIRED / DID_RENEW). Per the documentation, entering billing retry should produce a DID_FAIL_TO_RENEW notification. This is not a missed/undelivered webhook on our side: over the same 180-day window the global Get Notification History returned 4232 notifications and our records contain all of them, with per-type counts matching exactly (including DID_FAIL_TO_RENEW). For contrast, another subscription in the same billing-retry state (originalTransactionId 220002005208565) DID receive a DID_FAIL_TO_RENEW — so the absence is not universal, and it correlates with subscriptions extended via the API. The three affected subscriptions span three storefronts (USA / CHN / TUR), so it is not storefront-specific. Affected originalTransactionIds: 150002285191456 (extended to 2026-05-07) 320002313172683 (extended to 2026-06-05) 470002485799388 (extended to 2026-06-12) Questions: Should a subscription extended via Extend Subscription Renewal Date emit DID_FAIL_TO_RENEW when it later enters billing retry? If so, why is it absent from Get Notification History for these three while present for 220002005208565? Does extending via the API affect generation/visibility of subsequent renewal/billing notifications? How should we reconcile entitlement for subscriptions that entered billing retry without any notification?