The notification webhook is marketed as a way to get server-side updates on changes to in-app subscriptions. In the normal case, you can use that information to know the current state of a subscription. However, the retry system means that a notification may come up to 72hrs after the actual state change occurred and that also means that notification may be out-dated (another state change occurred between the time it was intended to be sent and the time it actually got successfully sent).
How are we supposed to ensure that a received notification is the current state of a subscription? Can we used the signedDate
to determine the order of notifications? (ie. when a notification fails to be sent and is resent, is the signedDate
not altered so it can be used to order the notifications?)
Or do we need to always make a request to the /inApps/v1/subscriptions/
endpoint to get the latest state and not rely on the contents of the notification?
There was an update to the docs at https://developer.apple.com/documentation/appstoreservernotifications/data when they added a "status" field:
The status of an auto-renewable subscription as of the signedDate in the responseBodyV2DecodedPayload.
This seems to imply that the signedDate
can be used to order the notifications. (though, the wording doesn't negate the possibility that they update the status
when they re-sign the notification, but that seems less likely then them just resending the same already signed payload)