How are App Store Server Notifications verified?

Each notification is a JWS whose certificate chain roots in Apple's CA, so there is no shared secret on either side and nothing to rotate. The first notification that verifies records your bundle id, and every notification after it has to match.

Which App Store notification types raise an alert?

The catalogue covers new subscribers, failed renewals, expiries and refunds, and all four ship switched off: a live app would otherwise mean a phone buzzing on every sale. Turn on the ones worth hearing. A type with no rule is recorded rather than guessed at, and the dashboard lists what has actually arrived so you can write a rule for it.

Does this replace App Store Connect?

No. It tells you a thing happened, at the moment it happened. Revenue reporting, trends and payouts are App Store Connect's job.

For App Store developers

Hear a subscription the moment Apple says so.

App Store Server Notifications V2 are a webhook, and a webhook needs a server. If your app has no backend, there is nowhere for Apple to post and nothing tells you about a subscription, a renewal or a refund until you next open App Store Connect. Paste an Acciti ingest URL in instead, and it arrives on your phone.

Get an ingest URL Read the docs

How do you receive App Store Server Notifications without a server?

Make a connector, copy its ingest URL, and paste it into App Store Connect as your production server URL. Acciti verifies the signed notification, decodes it, and turns it into a push on every device you are signed in on. There is no handler to write, nothing to deploy, and nothing to keep running.

App Store Connect takes a sandbox URL too. Point it at a second connector and a test purchase arrives as its own sender, with its own sound, rather than as something you have to read to tell apart.

How is an App Store notification verified?

Apple signs each notification with a certificate chain, so there is no secret on either side and nothing to leak or rotate. The first notification that verifies records your bundle id, and everything after it has to match.

The bundle id check is the part that matters and the part most relays skip. Verifying the signature proves Apple sent it. It does not prove the notification is about your app, because every developer's notifications are signed by the same chain. Without the second check, anybody who learns an ingest URL can replay their own app's genuine notifications into your feed.

What do you actually hear?

What you switch on. The catalogue ships entirely off, because a live app means a phone that buzzes on every sale and that is a notification people turn off in a week.

SUBSCRIBEDA new or returning subscriber.: Quiet
DID_FAIL_TO_RENEWA renewal failed and is in the billing retry period.: Normal
EXPIREDA subscription expired.: Quiet
REFUNDA purchase was refunded.: Normal

Anything else Apple sends is recorded and rings nobody. The dashboard lists the types your connector has received and has no rule for, so the catalogue grows from what your app actually emits rather than from a guess about it.

What the message says is yours

A rule owns the title, the body and the sound. The body is a template over the decoded payload, so a sale can name the product that sold.

A rule for a new subscriber

{  "eventType": "SUBSCRIBED",  "priority": 0,  "titleTemplate": "New subscriber",  "bodyTemplate": "{{productId}}",  "enabled": true}

A sound per event: A till for a sale and something duller for a refund, so you know which one it was from across the room without looking.
It reaches the watch: Register once on each device. A phone can be face down in another room; the watch is on your wrist either way.
Nothing to keep running: No function, no queue, no certificate to renew. If your app has no backend today, it still has none tomorrow.
Not a replacement for App Store Connect: This tells you a thing happened at the moment it happened. Trends, payouts and reporting stay where they are.

Questions

How do you receive App Store Server Notifications without a server?: Paste an Acciti ingest URL into App Store Connect as your production server URL. Acciti verifies the signed JWS, decodes it, and turns each notification into a push on your phone. There is no webhook handler to write and nothing to deploy.
How are App Store Server Notifications verified?: Each notification is a JWS whose certificate chain roots in Apple's CA, so there is no shared secret on either side and nothing to rotate. The first notification that verifies records your bundle id, and every notification after it has to match.
Which App Store notification types raise an alert?: The catalogue covers new subscribers, failed renewals, expiries and refunds, and all four ship switched off: a live app would otherwise mean a phone buzzing on every sale. Turn on the ones worth hearing. A type with no rule is recorded rather than guessed at, and the dashboard lists what has actually arrived so you can write a rule for it.
Does this replace App Store Connect?: No. It tells you a thing happened, at the moment it happened. Revenue reporting, trends and payouts are App Store Connect's job.

Stripe, GitHub, Sentry, Grafana and Better Stack connect the same way. See every connector.

Hear the next sale.

Sign in, make an App Store connector, and paste its URL into App Store Connect. The next notification Apple sends arrives on your phone.

Get an ingest URL