Apple's StoreKit Server API — a practical guide for indies

Apple shipped the App Store Server API quietly a few years ago and has been improving it steadily since. It is the most underused power tool in indie iOS, partly because it is poorly documented and partly because RevenueCat abstracts the same thing behind a nicer surface. This is a practical walkthrough for the case where you want to use it directly.

What the API gives you

Three concrete capabilities:

1. Server-side subscription status lookup — given a user's transaction ID, ask Apple's servers what their current subscription state is, signed and authoritative.
2. Server-to-server notifications (V2) — Apple POSTs a signed payload to your endpoint whenever a subscription event occurs (renewal, refund, downgrade, cancellation, billing retry).
3. Refund and entitlement management — programmatically issue refunds, extend entitlements, and look up transaction history.

If you have a backend and you sell subscriptions, you need at least notification handling. The other capabilities are situationally valuable.

The minimum viable setup

For a small indie studio, here is the minimum viable backend:

• A JWT-signing service (5 minutes of work) that mints the Authorization token for App Store Server API calls. The keys come from App Store Connect → Users and Access → Keys → In-App Purchase.
• A notifications endpoint that receives Apple's V2 webhook, verifies the JWS signature, and persists the event.
• A status-lookup endpoint your app can call to confirm subscription state.

We run all three on Cloudflare Workers. Total monthly cost: free at our volume.

The hard part — verifying the JWS signature

This is where most indies give up and switch to RevenueCat. Apple's notifications come as a signed JWS payload. To verify it, you need to:

1. Decode the JWS header.
2. Extract the certificate chain.
3. Verify the chain back to Apple's root CA.
4. Verify the signature.
5. Decode the payload.

There are libraries that do this. In Node, @apple/app-store-server-library is the official one. Use it. Do not roll your own JWS verification.

What we use it for

• Cross-device entitlement sync. A user buys on iPhone; the iPad recognises it via our backend within seconds.
• Refund analytics. Apple tells us when a refund happens. We log it. Refunds are the loudest signal in our retention data.
• Server-driven content. Premium content tiers are served only to verified subscribers, regardless of what the client claims.

When you do not need this

If your app is fully client-side, has no backend, and serves no server-side content, you do not need the Server API. StoreKit 2 on the device is enough.

If your app has a backend at all, hooking up the server-to-server notifications is worth a day of work. The retention insight alone repays the cost.

A final note

Apple's documentation for this API is improving but still not great. The official sample code repository is more useful than the docs. Read it.

If you get stuck on the JWS verification step, write us. We have working code we are happy to share.