For developers · Checked 30 September 2026

App Store Server Notifications V2: switching from V1 and handling every event

Short answer: Apple’s documentation marks the V1 endpoint and version 1 notifications as deprecated and tells developers to implement V2. Version 2 sends a signedPayload in JWS format that you verify on your server, retries a failed post five times over about a week instead of three, and lets you recover missed events with Get Notification History. You choose V1 or V2 per environment in App Store Connect; Apple recommends testing V2 in sandbox first.

Which notification each event sends

From Apple’s notificationType documentation, read 30 September 2026. A selection of the most common events; subtype is empty where the table shows a dash.

EventnotificationTypesubtype
Consumable, non-consumable or non-renewing purchaseONE_TIME_CHARGE-
First subscription in a groupSUBSCRIBEDINITIAL_BUY
Resubscribe after expirySUBSCRIBEDRESUBSCRIBE
Successful auto-renewalDID_RENEW-
Renewal fails, billing retry startsDID_FAIL_TO_RENEW- or GRACE_PERIOD
Billing retry recovers the subscriptionDID_RENEWBILLING_RECOVERY
User turns off auto-renewDID_CHANGE_RENEWAL_STATUSAUTO_RENEW_DISABLED
Upgrade or downgrade in the groupDID_CHANGE_RENEWAL_PREFUPGRADE or DOWNGRADE
Subscription ends after cancellingEXPIREDVOLUNTARY
Billing retry ends without recoveryEXPIREDBILLING_RETRY
Apple refunds a transactionREFUND-
Apple asks for consumption data on a refund requestCONSUMPTION_REQUEST-

What changes from V1 to V2

A V1 post is a plain JSON object with the latest receipt in unified_receipt. A V2 post carries a signedPayload, signed by the App Store in JWS; inside, the data object holds the transaction and renewal info, also JWS-signed, in the same format that StoreKit 2 and the App Store Server API use. So one decoding and verification path covers all three. V2 names events with a notificationType plus an optional subtype, instead of V1’s notification_type values, and adds events V1 never had, such as ONE_TIME_CHARGE and CONSUMPTION_REQUEST.

Setting up the endpoint

Your server must support TLS 1.2 or later. In App Store Connect, enter a production URL and, optionally, a sandbox URL; they can be the same. If you specify a port, it must be 443 or 1024 and above. If your server only accepts allowlisted IPs, allow the subnet 17.0.0.0/8, which covers sandbox and production. To move an existing app, point the sandbox URL at your V2 handler, test, then switch production to version 2.

Responding, retries and missed notifications

Reply with HTTP 200 to 206 when you handled the post; any 40x or 50x makes the App Store retry, and other codes count as a failure. For V2 the App Store retries five times, at 1, 12, 24, 48 and 72 hours after the previous attempt; for V1, three times, at 6, 24 and 48 hours. Retries happen only in production; sandbox sends once. After an outage, call Get Notification History for V2 events, or read the current state with Get Transaction History and Get All Subscription Statuses in the App Store Server API.

Testing your server

Call Request a Test Notification in the App Store Server API: the App Store sends a notification with type TEST to your configured URL, and Get Test Notification Status tells you how your server answered. The test always arrives in V2 format, even if the URL is still set to version 1, which makes it a quick check that your V2 parsing works before you switch.

New billing options send the same events

Apple’s newer subscription options reuse these notifications with extra fields rather than new types. A monthly subscription with a 12-month commitment, for example, keeps sending DID_RENEW every month after a user cancels, and marks the end of the commitment in its own fields; see monthly subscriptions with a 12-month commitment. For the review side of a new product, see how to submit an In-App Purchase for review.

Where Censuus fits

Reliable purchase events keep revenue correct; being found brings the purchases. Censuus ranks apps by the visits they draw, and adding your app is free on the List my app form. Placement comes from traffic and sponsorship: apps climb on the visits they draw, and a sponsor can pay to rise higher.

Frequently asked questions

Is App Store Server Notifications V1 deprecated?

Yes. Apple’s documentation marks the V1 endpoint and version 1 notifications as deprecated and says to implement the V2 endpoint instead. Apple has not published a shutdown date.

How do I switch to V2?

Build a V2 handler that verifies the signedPayload, set it as the sandbox URL in App Store Connect with version 2, test, then change the production URL to version 2.

How many times does Apple retry a failed notification?

For V2, five times, at 1, 12, 24, 48 and 72 hours after the previous attempt. For V1, three times, at 6, 24 and 48 hours. Retries only happen in production.

How do I test App Store Server Notifications?

Call Request a Test Notification in the App Store Server API. The App Store sends a TEST notification in V2 format, and Get Test Notification Status shows your server’s response.

Which IP addresses send App Store Server Notifications?

Apple says to allow the subnet 17.0.0.0/8, for both sandbox and production.

Guides for app developers

Put your app in the ranking

Censuus ranks apps by the visits they draw and by sponsorship, no bots. Listing is free; sponsorship raises placement.

Submit your appSee sponsorshipIndie app landscape: apps and visits by category