App Store Server Notifications: Your Backend's Source of Truth

App Store Server Notifications are webhooks from Apple that tell your backend about subscription events like renewals or refunds. They are your server's source of truth for user entitlements, letting you grant or revoke access without relying on the client…
WHY IT EXISTS: Client-side app state is unreliable. A user can be offline, use a jailbroken device, or manipulate local data. To reliably manage paid entitlements, you need a secure, out-of-band communication channel directly from the App Store to your server.
THE MENTAL MODEL: Think of App Store Server Notifications as a direct, secure phone call from Apple's servers to your backend. When something important happens with a customer's subscription—they renew, their payment fails, they get a refund—Apple calls your server to let you know immediately, instead of relying on the customer's app to relay the message.
HOW IT WORKS: You provide a secure HTTPS endpoint on your server in App Store Connect. When a subscription event occurs for one of your users, Apple's servers send a POST request to your endpoint. The request body contains a JSON Web Signature (JWS) payload. Your server must parse this payload, verify its cryptographic signature using Apple's public key to confirm its authenticity, and then process the event, for example, by updating the user's subscription status in your database. Key notification types include SUBSCRIBED, DID_RENEW, EXPIRED, and REFUND.
WHEN TO USE IT: Always use server notifications if your app has any form of auto-renewing subscription or non-consumable in-app purchase. They are the only reliable way to keep your user entitlement system in sync with the App Store's records. This is critical for granting, extending, or revoking access to paid features.
WHEN NOT TO USE IT: There is virtually no scenario where you would choose not to use them for subscriptions. For simple, one-time consumable purchases where a user gets an immediate in-app benefit (like game currency), you might rely solely on client-side receipt validation for simplicity, but this is still less robust. For any recurring revenue model, they are non-negotiable.
ONE CANONICAL EXAMPLE: A user's subscription is set to expire. Their credit card is charged successfully. Apple's servers send a DID_RENEW notification to your backend endpoint. Your server verifies the JWS signature, decodes the payload, identifies the user, and updates their subscription_expires_at date in your database to one month in the future. The user experiences no interruption in service. Later, if that user requests and receives a refund through Apple Support, your server gets a REFUND notification and can immediately revoke their access.
Read the original → developer.apple.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.