App Store Server Notifications are server-to-server messages Apple sends to a URL you configure whenever a subscription event happens: a renewal, a cancellation, a refund, a failed payment. They let a backend keep its view of subscription status accurate in real time instead of polling Apple. The honest answer to the title, for most indie apps, is no: if you use RevenueCat, it consumes these notifications for you, and you never stand up an endpoint of your own. You need one only when you run your own backend that must react to subscription events.
This post explains what the notifications (version 2) actually send, how they differ from the App Store Server API, and how to decide whether your app needs its own endpoint or can let RevenueCat handle it.
On this page
- What App Store Server Notifications are
- The events that matter
- Notifications vs the App Store Server API
- Do you need your own endpoint?
- Setting one up if you do
- FAQ
What App Store Server Notifications are
When you enable them, Apple sends an HTTPS POST to your server every time something happens to a subscription or purchase. Version 2 (the current one) delivers the payload as a signed JWS, the same signed format StoreKit uses on-device, so your server verifies Apple's signature before trusting it, exactly as described in StoreKit 2 transaction verification.
A decoded notification tells you the event type and carries the signed transaction and renewal info:
{
"notificationType": "DID_FAIL_TO_RENEW",
"subtype": "GRACE_PERIOD",
"data": {
"signedTransactionInfo": "<signed JWS>",
"signedRenewalInfo": "<signed JWS>"
}
}The point of receiving these is real-time accuracy: your backend learns the moment a customer renews, cancels, enters a billing grace period, or gets refunded, without repeatedly asking Apple for status.
The events that matter
There are many notification types, but a handful cover most of what a subscription backend cares about:
- SUBSCRIBED and DID_RENEW. A new subscription started, or an existing one renewed. This is how you keep a paid flag current.
- DID_FAIL_TO_RENEW. A renewal payment failed. The
GRACE_PERIODsubtype tells you the customer still has access while Apple retries, which pairs directly with enabling the billing grace period. - EXPIRED and GRACE_PERIOD_EXPIRED. The subscription actually ended. Now you revoke server-side access.
- DID_CHANGE_RENEWAL_STATUS. The customer turned auto-renew off or back on, an early churn signal worth acting on before they lapse.
- REFUND and REVOKE. Money was returned or access was pulled, so you should remove entitlement and, for family-shared purchases, handle the affected members.
- OFFER_REDEEMED and PRICE_INCREASE. An offer code or promotional offer was redeemed, or a price change is pending consent.
You do not need to handle every type on day one. Renewals, failures, expirations, and refunds are the core set that keeps a server-side entitlement honest.
Notifications vs the App Store Server API
These are two halves of Apple's server-side toolkit, and it helps to keep them straight:
- App Store Server Notifications are push. Apple tells you when something changes. Good for reacting in real time.
- The App Store Server API is pull. You ask Apple for a subscription's current status or transaction history on demand. Good for reconciling state, onboarding a new backend, or recovering after a missed notification.
Robust backends use both: notifications to react immediately, and the API to verify or backfill, since a notification can be delayed or missed and should never be your only source of truth.
Do you need your own endpoint?
This is the decision most indie developers actually face, and the answer is usually no:
- If you use RevenueCat, you generally do not need your own endpoint. RevenueCat receives and processes App Store events for you and keeps entitlement status current, which it exposes through its API and its own webhooks. Your app checks
customerInfo, and RevenueCat has already done the server-side reconciliation. For a client-only app, that removes the entire reason to run an endpoint. This is one of the quieter reasons to route subscriptions through it, covered in adding subscriptions with RevenueCat. - You do need one when you have your own backend that must react to events. Cross-platform entitlements shared with a web or Android app, server-gated premium content, custom churn emails, or your own analytics pipeline are all cases where your server has to know about renewals and refunds directly. Even then, RevenueCat's webhooks are often an easier integration than raw App Store notifications.
The trap is building a notification endpoint reflexively because it sounds necessary. For a purely client-side iOS app on RevenueCat, it usually is not.
Setting one up if you do
If your architecture genuinely needs it, the shape is straightforward:
- Configure the URLs in App Store Connect. You set separate production and sandbox notification URLs, so test events do not hit your production handler.
- Verify the signature. Decode the signed JWS and validate it against Apple's certificate chain before trusting the payload. Apple's App Store Server Library does this for you in several languages, so you do not hand-roll crypto.
- Respond quickly with 2xx and process asynchronously. Acknowledge fast and do the real work off the request path. Apple retries on failure, so make your handler idempotent to tolerate duplicates.
- Reconcile with the App Store Server API. Because a notification can be missed, periodically confirm status through the API rather than trusting your event log alone.
FAQ
What are App Store Server Notifications?
They are server-to-server messages Apple sends to a URL you configure whenever a subscription or purchase event occurs, such as a renewal, cancellation, billing failure, or refund. Version 2 delivers them as signed JWS payloads your server verifies before acting on them.
Do I need App Store Server Notifications if I use RevenueCat?
Usually not. RevenueCat processes App Store events for you and keeps entitlement status current, which it exposes through its API and webhooks. A client-only iOS app on RevenueCat generally does not need to run its own notification endpoint.
When do I actually need my own endpoint?
When you have a backend that must react to subscription events directly: cross-platform entitlements, server-gated content, custom emails, or your own analytics. Even then, RevenueCat webhooks are often simpler than consuming Apple's notifications directly.
What is the difference between notifications and the App Store Server API?
Notifications are push (Apple tells you when something changes) and the Server API is pull (you query current status on demand). Robust backends use both, notifications to react in real time and the API to verify or backfill missed events.
Which notification types should I handle first?
Renewals (SUBSCRIBED, DID_RENEW), failures (DID_FAIL_TO_RENEW), expirations (EXPIRED, GRACE_PERIOD_EXPIRED), and refunds (REFUND, REVOKE). Those keep a server-side entitlement accurate without handling every possible type on day one.
How do I verify a notification is really from Apple?
Decode the signed JWS payload and validate it against Apple's certificate chain, which Apple's App Store Server Library handles for you. Never trust a notification's contents before verifying its signature.
Whether you run a notification endpoint or not, the goal is the same: an accurate, server-verified view of who is subscribed, without building subscription infrastructure yourself. Spaceport gets you there by routing subscriptions through RevenueCat, whose server already reconciles App Store events, over products it creates and prices in App Store Connect through the API, in a generated SwiftUI project with the paywall, purchase, and restore flow wired to that verified status. For most indie apps that means you never stand up a notification server at all. And when you are lining up a waitlist and launch-day audience for the app, our sister tool Lighthouse covers that side.
From an indie iOS dev, for indie iOS devs.